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INTRODUCTION 


The Simulation Computer System (SCS) is the computer hardware, software, 
and workstations that will support the Space Station Freedom (SSF) Payload Training 
Complex (PTC) at MSFC. The PTC will train the SSF station operators, payload 
scientists, station scientists, and ground controllers to operate the wide variety of 
experiments that will be on-board the Freedom Space Station. 

This SCS Baseline Architecture Report summarizes the further analysis 
performed on the SCS Study as part of Extension Task 2 - "Develop an SCS Baseline 
Architecture" - of the SCS Study contract extension. These analyses were performed 
to develop the most cost effective solution to the PTC/SCS development requirements, 
and to identify and quantify the SCS cost drivers. 

To accomplish this task the TRW team performed the following 

steps: 

• Compiled from available sources current payload training requirements for 
SSF payload deployments. This included reviewing the requirements as 
stated in the SCS Concept Document, review of the Training FCD, and 
numerous meetings with the MSFC Training Branch personnel. 

• Compiled and reviewed current technical design information from WP02 on 
DMS Kits, SSE simulation, simulation control, simulation standards, 
hardware and software standards, and SIB. We also reviewed existing 
SSTF interface requirements and design, and the PTC/SSTF Interface 
Requirements Document (IRD). 

• Reviewed the above information with MSFC Training Branch to identify the 
minimal set of training and simulation requirements that must be met by a 
cost effective baseline AC PTC/SCS configuration. 

• Identified the PTC/SCS cost drivers, identified realistic definitive options, 
and developed a table that allowed quantifiable choices leading to the most 
cost effective baseline solution. 

• Defined AC baseline software architecture details 

• Defined AC baseline hardware architecture details. 
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1.0 TRAINING REQUIREMENTS 
1.1 TRAINING OBJECTIVES 

The objectives of training at the PTC/SCS are shown in Figure 1 . The Onboard 
Training was removed during the CBR scrub, but is shown in Figure 1 for traceability 
purposes. There is currently a CR that has been submitted to reinstate some form of 
onboard training, but for now onboard training is out of the program, and will not be 
further considered in the SCS Study. Previously (see SCS "Study Analysis Report", 
Issue T-20), it was concluded that onboard payload training requirements were best 
met via portable audio/video tapes and disks, or self contained PC based simulations. 

The Consolidated Payload Simulation training purpose of training crew in the 
PTC with personnel at the ROCs, DOCs, and UOFs is a new requirement on the 
PTC/SCS, and thus is not currently incorporated in the PTC or SCS requirements. If 
the POIC is involved in all of the Consolidated Payload Simulation training sessions, 
this requirements should have little affect on the PTC/SCS requirements. If however, 
the PTC/SCS is to conduct this type of training without the POIC, the PTC/SCS would 
have to simulate the POIC, and even potentially the SSCC. For example, if the PI at a 
ROC, DOC, or UOF exceeded his resource allocation, the POIC would intercede. If the 
PI then requested additional resources, the Onboard Short Term Plan (OSTP) would 
have to be redone. This is an SSCC function. 
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Training Type 

Objective 

Computer Based Training 

Will train individual students utilizing scenarios 
without instructor intervention -- basic use will be to 
provide preliminary or introductory instruction via 
screen text and graphics combined with questions to 
which the student would respond. 

Part-Task Training 

Primarily for developing single crew member 
operating skills associated with individual payload 
flight operations. Will also be utilized for the 
development of ground support personnel operating 
skills associated with individual payload operations. 

Combined Training 

Primarily for training a team of 2 or more crew 
members to operate multiple payloads combined into 
specific labs. Supports the combination of crew 
members and ground support personnel for training 
on payload operations specific to a lab. 

Consolidated Training 

Primarily for training 4 or more crew members 
located in Freedoms modules or the combination of 
crew members and ground support personnel for 
training on integrated payload operations throughout 
the entire manned base. 

SSTF Integrated Training 

Allows a student team to train on an entire mission 
increment at JSC with payload simulators running in 
a full-scale mode with the SSTF. 

Consolidated Payload 
Simulation 

Purpose is training crew at the PTC with teams of 
students at other operations centers, (e.g. the POIC 
and/or user operations centers - ROCs, DOCs, and 
UOFs) on specific flight increment objectives 
including reworking the short term plan, payload 
operations and updates, interactions with telescience 
operators, shift handovers, and payload 
malfunctions. 

POIC Training 

POIC Cadre members and certain representatives of 
remote operations centers can train on POIC 
systems, protocols and procedures using a 
representative subset of POIC components. 


Figure 1. PTC/SCS Training Objectives 
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1.2 TRAINING LOADING ANALYSIS 

The estimation of the training loading on the SCS was an iterative process that was 
complicated by the lack of detailed definition of the Space Station Program. There is 
little experience/data to draw from that is considered to be directly applicable to the 
Space Station training hour estimation. An initial estimate was evaluated in the 
original study. In this study extension, a detailed analysis was performed using 
Spacelab data and current definition of the Space Station Program. A final analysis 
was also performed with new training hours estimates and the latest OSSA payload 
traffic schedule, inputs from the Spacelab J mission training manager, and the current 
best estimates from the WP01 prime contractor. The detailed analysis is presented in 
Appendix C as a reference. The following section presents the final analysis and 
conclusion of the study analysis that was performed in each step of this training 
estimation process. 

1.2.1 Final Training Loading Analysis 

The review of the Spacelab analysis (See Appendix C) by training personnel 
indicated that the estimated number of total training hours was too large. A number of 
questions were raised concerning the applicability of Spacelab and particularly the 
Astro mission. Therefore, NASA training personnel and WP01 contractor personnel 
were tasked to develop an independent estimate of crew training hours. Using this 
latest data, the increment flow was analyzed to determine concurrent training 
operations. 

One other item that was questioned was the changeout rate which was assumed to 
be 15% of the payloads each 90-day increment. Using the OSSA Space Station 
Program Payload Traffic Model dated 10 May 1990, the changeout rate was re- 
evaluated. The calculation is based on the scheduled racks at AC and the scheduled 
changes over the next 4 years. The rate is calculated as follows: 

Number of racks at AC = 13 

Number of racks changed out in 4 years = 2.5 

Changeout rate for 4 years = 2.5/1 3 = ~1 9% 

Changeout rate per year = 1 9%/4 = ~5% 

Changeout rate per increment = 5%/4 = 1.25% 

Due to the uncertainties of current schedules, we will assume a 5% changeout rate 
to ensure a reasonable upper bound. Also, the changeout rate only affects the PI and 
PTC personnel support and not the number of crew to be trained. Therefore, it has a 
minimal impact on the overall requirements. 

The following sections provide the updated analysis based on the new training 
estimates received from WP01 personnel and the new changeout rate. 
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1. 2.3.1 Crew Training 

Analysis shows that the driving factor for facility needs is the number of concurrent 
training sessions required to support the increment training schedule. Therefore the 
new hour estimates were mapped onto the increment flow to determine the 
concurrency. The hours developed per crew member (excluding the station operator) 
are: 


PTT hours 300 

Modules hours 535 

The time frame used in our final analysis for training in the PTC is between L-12 
and L-6 which affords 6 months. Since the latest training estimates only consider crew 
training expected on PTTs and in the module trainer, the remaining hours in the 6- 
month window were split between CBT/Classroom training and consolidated training. 
The resulting schedules are pictured in Figure 1.2-1 for 45-day increments and Figure 
1 .2-2 for 90-day increments. 

The new estimates from this analysis are as follows: 


CBT/Classroom Training 

105 

hours 

Part Task Training 

300 

hours 

Module Training 

535 

hours 


Hnsi!i 



Total hours in 6-month window 1040 hours 


1 .2.3.2 POIC Training 

The only changes to the POIC training are due to the assumed 5% changeout 
rate which affects the incremental training. The training hours are: 

New Personnel 


No changes from prior analysis - 4075 CBT training hours per year 



Number 
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Figure 1 .2-1 . Final Training Increment Flow Analysis - 90-Day Payload lncrements/45-Day Crew Increments 
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Figure 1 .2-2. Final Training Increment Flow Analysis - 90-Day Payload lncrements/90-Day Crew Increments 
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Incremental Training 

Assume 4 hours CBT per experiment 

Assume 2 experiments per increment (5% changeout) for U.S. Lab 

Assume 1 experiment per increment (5% changeout) for U.S. sponsored in IP 

Assume 5 crews of 25 (125 personnel) 

125 (personnel) X 3 (experiments) X 4 (hours) = 1500 hours per 90-day 
increment 

4 increments/year X 1 500 = 6000 hours/year 

1. 2.3.3 Principal Investigator Support 

The 5% changeout rate modifies the calculations as follows: 

CBT Training (2 U.S. Lab exp. X 4 hours training) = 8 hours/increment 

4 increments/year X 8 =32 hours/year 

U.S. Lab PTT use per increment (2 exp. X 80 hours/exp.) = 160 

hours/increment 

IP PTT use per increment (1 exp. X 80 hours) = 80 hours 

1. 2.3.4 PTC Personnel 

The PTC personnel support estimation is modified due to the new changeout rate. 
The CBT hours for new personnel remains at 280 per year. The calculation for 
incremental CBT course development must now assume only 3 experiments per 
increment for U.S. Lab and IP. Therefore, the additional CBT hours are: 

3 exp. X 20 (hours for each exp.) = 60 hours per 90-day increment 

1. 2.3.5 Training Resource Estimate 

The new estimation of concurrent sessions and the new hours estimates does 
impact the prior resource estimation. The following sections re-evaluate the 45-day 
and 90-day crew increments for facility resource needs. 

1.2.3.5.1 45-Day Crew Increments 


£BI 


1 crew of 4 training simultaneously 4 

New POIC personnel 2 

Incremental POIC personnel training 3 
PI and PTC personnel support 1 


Number of concurrent CBT sessions 1 0 
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EH 


2 crews training simultaneously (2 per PTT) 4 

PI s upport 1 

PTTs in concurrent use 5 

Based on the number of U.S. Lab experiments (43) and the number of U.S. 
sponsored experiments in the IP modules (17), the configuration of PTTs includes 
U.S. Lab (2 PTTs for U.S. Lab payloads) and IP (1 PTT for JEM and 1 PTT for 
Columbus). Some time on the PTTs must be available to support the PI activity for 
payloads in the different IP modules, but the demand for U.S. Lab PTTs indicates the 
need for an additional PTT for the PI support. Since the PTTs will be different for each 
module, this implies that a total of seven PTTs must be available to meet the possible 
training schedules and provide available time for PI support. The total number of 
configured PTT sessions that must be available at certain times in the training 
schedule are: 

PTTs for U.S. payloads in the U.S. Lab 5 
(4 for crew and 1 for PI support) 

PTTs for U.S. payloads in the JEM 1 

PTTs for U.S. pavloads in the Columbus 1 

Concurrently available PTT sessions 7 

Module 

Analyzing the training schedule shows two crews at a time will need to be trained, 
so two U.S. Lab modules will be necessary to support training. It is expected that a 
single Attached Payload Trainer will suffice to support training in the two U.S. Lab 
trainers. 

Consolidated 

Only one crew at a time will need to be trained, so only a single Consolidated 
Trainer will be necessary to support training. The Consolidated Trainer must include a 
U.S. Lab module, a JEM module, an Attached Payload Trainer, and a Columbus 
Module. Since the 45-day increment flow shows simultaneous use of 2 module 
trainers and 1 consolidated trainer, a third U.S. Lab module will be necessary. It is 
expected that the Attached Payload Trainer can be the same one used to support U.S. 
Lab module training. 

1.2.3.5.2 90-Day Crew Increments 

If we evaluate the needs based on a 90-day crew increment, only those numbers 
involving the crew training must be modified. The following estimates are based on 
the 90-day flow shown in Figure 1 .2-5. 
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CBT 

1 crew of 4 training simultaneously 4 

New POIC personnel 2 

Incremental POIC personnel training 3 
PI and PTC personnel support 1 


Number of concurrent CBT sessions 1 0 

EU 


1 crew training simultaneously (2 per PTT) 2 

PI support 1 

PTTs in concurrent use 3 

Based on the number of U.S. Lab experiments (43) and the number of U.S. 
sponsored experiments in the IP modules (17), the configuration of PTTs includes 
U.S. Lab (2 PTTs for U.S. Lab payloads) and IP (1 PTT for JEM and 1 PTT for 
Columbus). Some time on the PTTs must be available to support the PI activity for 
payloads in the different IP modules, but the demand for U.S. Lab PTTs indicates the 
need for an additional PTT for the PI support. Since the PTTs will be different for each 
module, this implies that a total of 5 PTTs must be available to meet the possible 
training schedules and provide available time for PI support. The total number of 
configured PTT sessions that must be available at certain times in the training 
schedule are: 

PTTs for U.S. payloads in the U.S. Lab 3 
(2 for crew and 1 for PI support) 

PTTs for U.S. payloads in the JEM 1 

PITs for U.S. pavloads in the Columbus 1 

Concurrently available PTT sessions 5 

Module 

Analyzing the training schedule shows only one crew at a time will need to be 
trained, so only a single U.S. Lab module and a single Attached Payload Trainer will 
be necessary to support training. There will be available time in the module trainer to 
support needed time for individual payload training. 

Consolidated 

will be necessary to support training. The Consolidated Trainer must include a 
U.S. Lab module, a JEM module, an Attached Payload Trainer, and a Columbus 
module. Since the 90-day increment flow shows simultaneous use of a module trainer 
and a consolidated trainer, a second U.S. Lab module will be necessary. It is 
expected that the Attached Payload Trainer can be the same one used to support U.S. 
Lab module training. 
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1.2.2 Training Loading Summary 


The biggest driver for the facility loading is the number of concurrent sessions that 
must be supported for the increment schedules. Therefore, the two possible crew 
increments of 45-day and 90-day make significant changes in the loading estimates. 
The final analysis performed using training hours estimates provided by NASA and 
WP01 training personnel and the latest payload traffic estimates are the best estimate 
that can be determined at this time. Therefore, the SCS components that are required 
to support the demand for concurrent operations at various points in the training 
schedule based on the latest PTC training estimates are listed below based on the two 
possible crew increments. 

45-Pav Crew increment 


CBT Stations 1 0 

Part Task Trainers: 

U.S. Lab 5 

JEM 1 

Columbus 1 

Total 7 


Module Trainers: 

U.S. Lab 2 

Atta ched Pa y lo ad 1 

Total 3 


Consolidated Trainer 1 

Includes: 

1 U.S. Lab module (additional U.S. Lab module) 
1 JEM module 
1 Columbus module 

1 Attached Payload (same module as above) 
90-Pav Cr ew Increment 


CBT Stations 1 0 

Part Task Trainers: 

U.S. Lab 3 

JEM 1 

Columbus 1 

Total 5 


Module Trainers: 
U.S. Lab 


1 
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A 




Pavload 


1 


Total 


2 


Consolidated Trainer 1 

Includes: 

1 U.S. Lab module (additional U.S. Lab module) 
1 JEM module 
1 Columbus module 

1 Attached Payload (same module as above) 
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2.0 RELATED SSFP DESIGN INFORMATION 


Since the PTC/SCS will use or interface to other SSFP elements, the 
requirements and design of these elements will have a strong influence on the 
PTC/SCS baseline architecture. A discussion of each of these key elements and the 
anticipated influences follows. 

2.1 SSTF DESIGN 

The same payload models that are used in the PTC are planned to be used in 
the SSTF for whole station training Utilizing a second set of payload models at the 
SSTF would not be cost effective, nor good training practice as there would inevitably 
be differences in the models. Additionally, the models transported from the PTC to the 
SSTF must arrive at the SSTF in a "plug and play" state. If a conversion or 
modification of the payload models is required when they arrive at the SSTF, this must 
be accompanied by an integration, test, and acceptance cycle. This type of activity 
would take some number of weeks, and neither the PTC nor the the SSTF training 
schedule contain weeks of slack. Since the actual payload is scheduled to begin flight 
integration at L-12 to L-9, the payloads model will be evolving as changes are made 
until L-6 and perhaps even later. Thus, the models will at best be mature and ready to 
ship at L-6. Consequently, there exists a derived requirement that payload models 
from the PTC be installed and ready to use at the SSTF in a few days at the most. 

CAE Link was awarded the SSTF development contract in October '89. They 
are currently performing requirements analysis, doing preliminary design, and defining 
Level B specifications. Since they have no budget or reason to develop a second set 
of payload models for each increment over the 30 year lifetime of the SSF, they are 
working to build a design that will permit the easiest transport of the PTC payload 
models to the SSTF. Thus the current SSTF design supports the transportability 
requirement, with one notable exception. The exception is that there is no provision in 
the current SSTF design for using flight equivalent Multiplexers/ Demultiplexers 
(MDMs), which means no support for flight equivalent payload hardware that 
interfaces to MDMs or payload flight software that executes in MDMs. 

As shown in Figure 2, there is a separate host computer in the SSTF called the 
Payload Session Computer to run the payload models. This computer interfaces to 
the C&D panels in the mockups (Hab, Lab and Nodes) via the Real-Time (RT) LAN, 
the DMS Kits via a SIB, and the Software Production Environment, IT&V, and 
Operations Support computer via the General Purpose (GP) LAN. The Multipurpose 
Applications Consoles (MPACs) are connected to the DMS Kit FDDI, just as the flight 
MPACs are connected to the DMS FDDI. The Payload Session Computer is 
connected to the Core Session Computer via the Session Real-Time (RT) LAN. 

No actual hardware has yet been selected to support the SSTF design. The 
most optimal selection to guarantee turn-key transportation of payload models to the 
SSTF would be to select the same host for the SSTF Payload Session Computer as is 
selected for the SCS, the same LANs for SSTF as for SCS, and the same Instructor 
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Figure 2. SSTF Systems Architecture 
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Operator Station (IOS) for the SSTF as for SCS. Since the SSTF and SCS designs 
are scheduled to be developed in parallel, the SSTF designers will not be able to 
simply copy the SCS for the payload portion of the SSTF. A good alternate design 
strategy is to follow SSE standards in selecting hardware and software. Where SSE 
has not specified hardware, select a common COTS product. The GP l_AN will 
probably be Ethernet. 

Another very important consideration is software compatibility. For simulation 
control, the simulation modes must be matched for the SSTF and PTC. Also, 
interfaces between software communicating over the RT LAN must be worked to be 
compatible. Another compatibility factor is that the requirements for what the payload 
models must simulate are different between the SSTF and PTC. For example, in 
SSTF Whole Station Training there is concern with things like payload venting that 
affect the SSF attitude, where as the PTC has no known need for a payload model to 
simulate venting. 

2.2 DMS KITS 

During the earliest phases of the SCS Study, a ground rule was baselined that 
the PTC would make maximum practical use of flight software. This decision was 
based on the Program Definition and Requirements Document (PDRD) SSP 30000 
requirement that "High fidelity training systems shall have the capability to use flight 
software" and lessons learned from the SpaceLab Payload Crew Training Complex 
(PCTC) relative to the impacts of simulating flight software in the training environment. 
The SCS requirements and conceptual designs were then based on the underlying 
assumption that both Space Station systems (e.g., C&T, OMA, DMS) flight software as 
well as payload flight software would be executed in the SCS supported by 
simulations. The SCS Study Phase One SDF Technical Demonstration showed the 
feasibility of this approach. Additional requirements were placed upon the SCS to 
support the use of flight equivalent or prototype payload hardware/software 
combinations in the training environment (per the PDRD section 4). 

At this point in the program, only DMS Kits offer the capabilities to execute flight 
software in a ground simulation environment. The DMS Kits consist of Functionally 
Equivalent Units (FEUs) of the DMS components along with functionally equivalent 
busses/networks and a Simulation Interface Buffer (SIB). No other environment has to 
date been identified to support the execution of flight software in an environment 
realistic enough to support training. Therefore, adequate DMS Kit functionality to 
support training coupled with a sufficient allocation of Kits and components to the SCS 
is absolutely central to the development of a workable SCS design that fulfills the 
requirements as stated above. 

The DMS Kit CEI Specification along with a subset of more detailed 
requirements was reviewed at the recent DMS PDR3. With minor exceptions that have 
been worked through the RID process, DMS Kit functionality will adequately support 
PTC/SCS requirements. However, the allocation of Kits and FEU components to the 
PTC is a matter of critical concern. A PTC requirement for 8 DMS Kits of varying 
composition (directly related to the intended Kit use - module trainer or part-task 
trainer) was submitted to the program. This number of Kits and required composition 
represented the best estimate - based on extensive training flow analysis - of the 
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minimum capability required for the SCS to fulfill the training requirements. Significant 
reduction in the PTC DMS Kit allocation from the original requirements is considered 
to be a major design driver on the SCS. 

The SCS requirement that payload simulators (hardware and software) be 
directly portable from Part-Task Trainers to Module Trainers to Consolidated Trainers 
to the SSTF is critical to minimizing simulator development costs. If the DMS Kit 
allocations are reduced such that some trainers (i.e., Part-Task Trainers) have no DMS 
Kit support, then payload software can not be used in that part of the PTC. If payload 
software can't be used, then payload simulators would be totally comprised of a 
software simulation (of both payload hardware and software) combined with 
appropriate C&D hardware mockups. This is equivalent to current practice in the 
PCTC. DMS Kits would only be used to execute system flight software. If the Kits are 
utilized purely for the execution of system flight software, the use of any Kits in the PTC 
is questionable due to the relationship between DMS Kit cost and the benefits derived 
from system flight software execution. 

2.3 SIB 

The Simulation Interface Buffer (SIB) is a key component of the DMS Kits. The 
SIB provides connectivity from the FEU DMS processors to the simulation host 
computer. It will provide capabilities to monitor all bus/network traffic on the 
local/global busses as well as simulate missing nodes on the networks. Capabilities 
for DMS fault insertion (e.g., lost messages, transmission errors) will also be provided. 

Until January, 1990, design responsibility for the SIB resided in the Lockheed 
SSE contract. In January, this responsibility was shifted to WP02/MDSSC as a part of 
the Integration, Test, and Verification Environment (ITVE). IBM has assumed 
responsibility for SIB design under subcontract to MDSSC. At the time of the design 
transition, SSE had recently completed a SIB Detailed Requirements Review. The 
requirements that were reviewed at that point adequately fulfilled the needs of the PTC 
with few exceptions. No commitment has been made by WP02 to use this set of 
requirements as formal inputs to the IBM SIB requirements specifications. It is 
expected that the IBM SIB requirements and design will be based on the existing IBM 
SIB prototype. Therefore, SCS participation in upcoming reviews of SIB requirements 
and design is critical due to the unwillingness of WP02 to consider overall program 
needs in the SIB requirements analysis process. 

Two significant drivers on the SCS design may be expected to materialize in 
the formal SIB documentation. First, the SIB is expected to interface with SSE-defined 
host computers (Architecture A - DEC Vax and Architecture B - IBM 3090 family). This 
interface is a point-to-point interface from the SIB directly to the host machine. No 
network interface is expected to be provided without significant cost impacts. 
Additionally, the Contract End Item Specification for DMS Kits (DR SY-06.1, March 
1990) specifies a SIB-to-Host interface speed of 5 Megabytes (40 Megabits) per 
second, and a burst rate of 6.7 Megabytes (53.6 Megabits) per second. The SIB is 
expected to be a device with minimal intelligence. The host computer should be 
expected to carry most of the processing load for message construction, data buffer 
sorting, data logging, and several other functions that SSE had originally intended to 
be resident in the SIB. 
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2.4 OMA 

The Operations Management Application (OMA) is the highest tier of onboard 
command and control software. The OMA is expected to be present in the SCS either 
as actual flight software executing in a DMS Kit Standard Data Processor (SDP) or as 
a simulation executing in the host computer. To support the execution of the OMA 
flight software, simulations of other OMA interfaces will be required (e.g., other SS 
systems and the OMGA). In either case, the OMA is not considered to be a significant 
SCS design driver. 

2.5 SSE/ITVE 

In the original SSE contract, Lockheed was given responsibility for providing to 
the program software development tools, rules, and procedures along with the 
simulation execution support environment (including the SIB design as discussed 
above). The development of the simulation execution support environment was 
shifted to WP02/MDSSC as a part of the ITVE. SSE has retained the responsibility for 
the provision of software development tools, rules, and procedures. The SSE 
workstation and tool selections therefore still impose design constraints on the SCS 
from a software development support standpoint. 

At the present time the ITVE's charter is to support integration and verification of 
work package flight software. Specific support for other functions is currently outside 
the scope of ITVE. Therefore, WP02 does not plan to respond to any specific 
requirements from facilities such as the PTC but the PTC may use the ITVE products 
"as is". Even with these constraints, certain portions of the ITVE software may be quite 
useful in the SCS if the SCS design is engineered to accommodate them. This 
software includes SIB interface, simulation configuration, simulation executive, 
simulation data base construction/access, and data logging/analysis. The fact that the 
ITVE software is targeted to the SSE-defined Vax and IBM computers is an additional 
SCS design driver. 

2.6 SIMULATION STANDARDS 
2.6.1 Simulation Control Method 

The ITVE is expected to provide a simulation executive that allows for cyclic 
execution of simulation models and a demand execution mode. The models will be 
bound to the executive and called as procedures by the executive task. A set of 
simulation interface services will allow the simulations to access and write data into a 
simulation object data base which is roughly analogous to the flight Runtime Object 
Data Base (RODB). 

The ITVE will define interface standards both for the simulation executive interface as 
well as the interface to the simulation object data base. These interface standards 
may be considered as ICDs for the simulations that will execute in the ITVE and as 
such will be the de facto interface standard for all program simulations that have 
portability as a requirement. If the SCS makes use of the ITVE simulation executive, 
simulation interface services, and other ITVE software, obviously this standard 
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interface will be supported. Even if the SCS forgoes use of ITVE software, the design 
of an SCS simulation controller should implement the ITVE-defined interface standard 
to allow the use of simulations developed for execution in the ITVE. 

2.6.2 Simulation Modes 

The ITVE simulation executive is expected to support all simulation modes 
required by the SCS. These modes include stop, start, pause (freeze), checkpoint 
(datastore), restart (reset), and stepahead. 

2.7 HARDWARE AND SOFTWARE STANDARDS 

From the above discussions, and the work done in the SCS Study Phase one, it 
is clear that standardization of hardware and software in the PTC/SCS has many 
benefits. The PDRD states "The training program shall attain as much commonality as 
is practical between media, the curriculum, and training facilities." 
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3.0 PTC/S CS ARCHITECTURE TRADEOFFS 


As a result of the Langley Configuration-Budget Review (CBR), there were over 
400 changes in the system. The CBR process placed great emphasis on lowering 
costs and holding to schedules. In order to evaluate the CBR affect on SCS, and 
facilitate future potential changes, PTC/SCS architectural tradeoffs were quantified 
and evaluated. This process of architectural tradeoffs was needed to allow us to 
define the most cost effective PTC/SCS baseline solution. Results of this effort are 
presented in this section. 

3.1 COMMON ARCHITECTURAL ELEMENTS 

These consist of hardware and software needed to meet the PTC/SCS 
requirements. 

3.1.1 Software Architecture 

Following is the list of software required for and supported by the PTC/SCS. 
The software is grouped by category to ease discussions and to aid in the graphic 
presentation of the hardware (with associated software) in the next section (3.1.2). 

Analysis Support 

Data Analysis - Provides the capability to retrieve and analyze data that was 
logged during a training simulation session. The software will support reduction of 
only those data records selected by the user and allow format definition for report 
generation. 

Data Logging - Provides the capability to log various data records produced during 
a simulation run with time tagging capability. This function will support the 
recording of all or selective data generated during a training session. 

Traininn Analysis - Assists the instructors in evaluating all training requirements, 
materials, and scenario development in advance of performing the training. 

Training Response Capture - This software function maintains a history of the 
student responses during a training session. The response will be tied to training 
session events to support later evaluation of the student. 

Training Result Analysis - Evaluates the training session responses of the student 
after the training session based on the analysis criteria which can be input by the 
instructor. This function provides for report generation based on instructor 
specification and transfer of data to the training management function. 

QBJ 

Authoring Software - The software system that provides the capability to develop 
courseware specific to a certain payload or increment of payloads. This software 
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CBT allows the instructor to define the training script/scenario and associate the 
scenario with graphics, audio, video, data, and expected responses. 

Courseware - The actual CBT software specific to a certain payload or increment of 
payloads that allows introductory or tutorial training without instructor intervention. 
This includes both question/answer type training sessions and selected interface 
prototypes with interactive capabilities. 

CBT Control Software - This software provides the interactive user interface, control 
of data, audio, and video components, and collection and analysis of student 
responses. 

Development Support 

C&D Panel Development - CAD/CAM system to support the design of the hardware 
panels. 

Crew Interface Prototyping - This function supports the rapid prototyping of the crew 
interface (MPAC displays, C&D Panels, etc.) to support the simulation developers 
investigation of requirements and to possibly support early training sessions. The 
crew interface prototype must conform to the USE standards. 

Developer Interface Functions - Software to supply the user interface for the SCS 
developers to interact with development tools and other system software. 

Primary Instruction Development - Support for the generation of instruction material 
including specification of curricula, classroom syllabi, course outlines, lesson 
summaries, etc. This function also supports the development of training objectives, 
selection of methods/media, development of the instructional plan, experiment 
overview, and the simulator approach. 

Training Requirements Development - Tools to support the requirements definition 
for payload training and development of associated training sessions 
requirements. 

Scenario Development - This software allows the instructor to generate scenarios 
to support particular training sessions. An interface will be provided to easily 
define the configuration and expected training steps. 

Software Development - This function provides the capabilities to support the 
requirements/design/code development for the SCS and simulation software. 
These capabilities support the initial development, the continued simulator 
development, and the maintenance/upgrade efforts. This will be an integrated set 
of tools which provides the following: 

CASE 

APSE 

Editor 

Compiler 



Linker 

On-line debugger 
Model Prototyping Tool 
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Flight Software 

C&T Software - This is the SSF software that supports C&T. 

DMS Software - This is the SSF DMS software which consists of the following 
functions: 

Data Storage and Retrieval 
MODB Manager 
Network O/S Manager (NOS) 

O/S Ada Real Time Environment (RTE) 

Standard Services 

System Manager 

User Support Environment (USE) 

OMA Software - This is the SSF on-board operations management software which 
consists of three levels: 

Tier I - Station Management 
Tier II - Element Management 
Tier III - Rack Management 

Pavload Software - The actual payload flight software. 

Ground Support Equipment 

GSE Control - This function controls all hardware which support the 
simulation/training session. This hardware includes the ground support equipment 
which provides operational needs for equipment within the PTC (power, coolant, 
etc.) or supplies stimuli to flight equivalent hardware. This function supports all 
necessary interfaces with real/prototype payload hardware and the DMS kits. 

Health and Status - Monitors the status information on all SCS equipment involved 
in the training session. This compiled information can be viewed by operations 
personnel for recovery purposes. 

PTC Training/Operatio ns Management 

Facility Scheduler - Provides the tools for the scheduling of the resources of the 
PTC to support the varied training sessions within the PTC (concurrent sessions 
schedules, maintenance schedules, upgrade schedules, etc.). This software will 
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also allow the incorporation of additional scheduling constraints of external 
resources to support scheduling with involvement of external facilities. 

General Purpose Tools - This category of software provides general tools for the 
support of administrative activities in the PTC. These include word processors, 
briefing chart generation support, spreadsheets, database management, etc. 

PTC Configuration Management - This function provides the management 
mechanisms for control of all hardware/software components in the SCS and 
associated documentation. The mechanisms include the capabilities to identify 
problems and modifications and impacts to related areas. The function also 
provides the history database of versions, facility utilization, and all related data. 

Training D atabase - Provides the capability to organize experiment and other data 
into a database in terms of mission purpose, major subsystems and components, 
operational policies and procedures, personnel responsibility, etc. This function 
will also provide the capability to analyze the data in the data base and identify all 
tasks necessary to operate, maintain, and control the experiment. 

Training Management - This software supports management of the students as 
they proceed through the various training phases. The function provides the record 
keeping on individual students and supports the scheduling of each student's 
training activities. The transfer of training records to TMIS is supported. 

SSFyPavload Database - Provides associated SSF and payload data that is 
required for SCS development of simulators, tests, training scenarios, etc. 

Session Manageme nt Functions 

Configuration and Setup - This function allows the SCS operations personnel to 
specify a configuration which includes the necessary hardware and software to 
support a particular training session. The software provides the capability to 
automate the creation of a run-time configuration file based on simulator 
configuration data and training plans. This function will automatically initialize the 
proper software simulation configuration. The extraction of setup and configuration 
data from crew procedures will also be supported. 

Instructor Interface - Provides an interactive mechanism for the instructor to monitor 
the training sessions and supply on-line control inputs for a session. 

Network Management - This function controls all the network interfaces throughout 
the SCS and monitors the network traffic. This software supports the message 
transfer for distributed operations during all modes of SCS operations. 

Operating System - This function consists of the operating systems for each 
processor in the SCS system. This software incorporates the device drivers 
necessary to support the hardware interfaces to all peripherals and other support 
equipment. 
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PTC External Communications - This function controls the real-time distribution of 
data (video, audio, CORE LAN data, Payload LAN data) to interfaces with external 
facilities such as the POIC, MPS, PI facility (UOF), etc. The interfaces for non real- 
time data transfer to external system such as TMIS, SSTF, etc. will also be 
supported. This software controls and monitors the hardware that supports these 
external interfaces. 

SCS Executive - Controls the software simulation configuration setup through 
management of the simulator incorporation (which simulators with what fidelity) for 
the specified training session. This software ensure that a specific training or test 
session is configured with the proper version of the software. This function controls 
the system modes (standard operations, trainee absent, and preventive 
maintenance) for the SCS. Receipt of non-real time training and simulation 
session data is also supported. 

Session Readiness Test - Provides a high level readiness check of all elements 
required for a particular training session. 

Simulation Executive Functions 

Simulation Executive - This software controls the order of model execution, 
supports the internal interfacing between models, supports the external interfaces 
to other software functions, and controls the simulation modes (run, stop, restart, 
etc.). The collection of simulation execution metrics is also supported. 

Test Executive - Controls the execution of test procedures to support the testing of 
simulation software by SCS developers and the IT&V personnel. This function 
provides an interface for test procedure definition. Proper delays and interactions 
with the simulation executive will provide execution of procedure steps. This 
software will support timeline verification, crew procedure verification, trainee 
absent mode and provide any specific features necessary to support test. 

Training Executive - Controls the execution of a scenario during a training session 
through interaction with student, instructor, external facility inputs and the 
simulation executive. A rule-based evaluation of student responses can be 
performed in real-time which can support the modification of a scenario based on 
student responses. This software supports insertions of faults during a scenario. 
The automatic generation of expected student responses will be provided to 
support the trainee absent mode. This software will support timeline verification, 
crew procedure verification, trainee absent mode and provides any specific 
features necessary to support training. 

Simulations 

DMS - Required or trainer with no DMS kits. 

Data Storage and Retrieval - Models the file manipulation functions necessary 

to support payload training. 
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MODB Manager - Model simulates the MODB functions necessary to support 
the payload training. The function will allow the definition of new objects that 
can be incorporated into a new RODB for payload simulation. 

Network Q/S Management fNQS) - Model simulates the DMS network aspects 
necessary to support payload training. 

Q/S Ada Real Time Environment (RTE1 - Modeling of a small portion of the RTE 
may be necessary to provide the transparent interfaces from application to 
application when the DMS is simulated and real payload software is present. 

Standard Services - This functions simulates the runtime management of RODB 
objects necessary to support payload training. This software performs the 
reading and writing of attributes, the reading and writing of commands on 
objects, and the reporting of events when object attributes violate predefined 
limitations. 

System Manager - This software simulates the DMS system manager functions 
necessary to support payload training. This function includes the startup and 
shutdown of DMS nodes and the monitoring and reporting of DMS errors, faults, 
overloads, and anomalies. 

User Support Environment - The user support environment must be simulated 
to the degree necessary to support payload training. This function will provide 
the user interface services to simulate the MPAC displays. 

Environment Models 

Various models which simulate the environmental conditions which will effect 
the SSF systems and payloads. Many of these models will support the GN&C system 
simulation. The models include the following: 

Aerodynamics model 
Atmosphere density model 
Gravitational forces model 
Lunar position and phase 
Magnetic field model 
Mass properties models 
Plasma effects model 
Rotating earth model 

Solar position model (orbital sunrise/sunset) 

South Atlantic anomaly model 
Station dynamics model 
Thruster firing model 
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Zone of Exclusion (ZOE) model 
Ground Systems 

Pavload Short Term Plan Generation - This function provides the capability to 
generate an STP for the payload(s) in a training session. This software is not 
intended to provide the capability of SSF STP generation, but could be a subset of 
that software. This is expected to be provided by MPS system. 

AFACTS model - Provides the simulation of the Onboard Short Term Plan 
generation to support the payload operations training. This software may be a 
subset of the AFACTS which is expected to be developed for use in the SSCC. 
Assume this runs on POIC computers as part of the Mission Planning System. Plan 
to use MPS for this capability. 

International Partners 

CAP Panel - Software required to drive the C&D panels in support of training 
exercises. This software will control the C&D panels in response to crew actions or 
data from payload simulations. 

JEM/Columbus System models - Provides the simulation of basic interface data 
between the JEM/Columbus systems and the JEM Lab. This function includes the 
International Partner system models required to support training on U.S. sponsored 
payloads. 

JEM Exposed Facility System models * Provides the simulation of basic interface 
data between the JEM Exposed Facility system and the JEM Lab. This function will 
include the JEM system models which support payload commanding and payload 
health and safety data acquisition for U.S. sponsored payloads. 

JEM Pointing System - This software simulates the functions of the JEM pointing 
system and responds to operator commands realistically enough to support 
training for the JEM pointing system itself and the payloads attached to it. 

Pp ylo ad S upport Equipment (P/L 5E) 

Attached Pavload Accommodation Equipment (APAE) Pointing Systems - Provides 
the simulation of the interactions between the pointing systems and the modeled or 
flight equivalent payload simulation. This model also produces all necessary 
equipment status to support other SSF simulations. 

Attached Pavload Accommodation Equipment (APAE) Systems - Provides the 
simulation of the interactions of accommodation equipment with the associated 
payload model or payload flight software. This software provides the appropriate 
equipment status information to support other SSF simulations. 

C&D Panel - Software required to drive the C&D panels in support of training 
exercises. This software will control the C&D panels in response to crew actions or 
data from payload simulations. 
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General Lab Support Facilities 

Life Science Glovebox - Model simulates command, control, health status and data 
forwarding between the LSG and the rack level processors. 

Materials Processing Science Glovebox - Model simulates start-up and normal and 
emergency shutdown. Functions provided also include system monitor and control 
including cabinet/airlock pressure/temperature/doors, filter and circulation fans, air 
quality and flow rate, access to FMS, NO2, UPW, particle counter, and clean-up 
and transfer in/out. 

Materials Science Workstation/Lab. Science Workbench - The workstation 
provides step by step procedures for conducting ORU and experiments 
maintenance. This model of the workstation simulates command, control, health 
status, and data forwarding between the MWS/LSW and rack level processors. 
Functions provided include monitor voltage, door interlock open/close and filter 
pressure data. Also included are command of blower motors, vent valves, and 
door enable. 

Pavload Support System (PSS) 

Centrifuge - This model will simulate the functions of the US Lab centrifuge and 
respond to operator commands realistically enough to support training for the 
centrifuge itself and the payloads processed within the centrifuge. 

Furnace - This model simulates the functions of the US Lab materials furnace 
and responds to operator commands realistically enough to support training for 
the furnace itself and the payloads processed within the furnace. 

Optical Work Bench - Simulates the functions of the US Lab flight article 
realistically enough to provide training for the work bench itself and for the 
manifested payloads that utilize the work bench. The model simulates image 
processing from impingement of the image upon the truss mounted large 
pointing mirror through reduction of the optical measurements to digital outputs. 

U S. Lab Pointing System model - Simulates the functions of the Instrument 
Pointing System or its SSF functional equivalent. The model will respond to 
commands realistically enough to support training for the IPS itself and 
payloads mounted on the system. 

Process Materials Management Subsystem fPMMS) - Functions simulated include: 

1) model of gaseous NO2 distribution to the user facilities and laboratory 
equipment 

2) Vacuum Vent system model which simulates vacuum of non-hazardous 
waste gas from the US Lab user facilities and provides command, control, 
and health and status data 
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3) Ultra Pure Water system model which simulates the provision of ultra pure 
water to payloads and lab equipment. 

Pavload Models 

Generic Simulator - Used to provide early payload training for the crew in the event 
that user payload models are not available. Also, used as a simple driver to test 
the payload-to-PTC interface. 

Pavload - Flinht Equivalent - This simulation requires flight equivalent hardware to 
allow execution of the payload flight software. This function will provide simulation 
of payload equipment/instruments that are not available in the PTC to support the 
stimulation of the flight equivalent software. 

Pavload Models - These models provide a full simulation of the payload including 
the flight software and hardware. 

Video - Pavload Image Generation - The SCS software which generates video 
images or graphical representations of the payload experiment to the student. This 
software provides a standard interface to payload simulators for manipulation of the 
images. 

C OR E Systems 

Audio - This software controls the audio components in the internal audio system of 
the IAV simulator and can support simulation of both the intra-station and ground 
communications. 

C&D Panel - Software required to drive the C&D panels in support of training 
exercises. This software will control the C&D panels in response to crew actions or 
data from payload simulations. 

Caution and Warning - Provides the simulation of C&W functions as necessary to 
support payload training. This software will generate appropriate system 
messages and alarms via panels and MPAC displays. 

Communication and Tracking fC&T) - Model simulates the onboard C&T system to 
a level required to support payload training including PTC-to-POIC integrated 
training sessions and interface requirements. Functions simulated include space- 
to-ground communications, high rate patch panel, high rate data recorder, voice 
recognition/synthesis, and interface to MPACs and core systems. 

Environmental Control Life Support System (ECLSS) models 


Air Revitalization System (ARS) - Simulates an interface to the payload 
manager software and the specific rack control manager. 

Atmosphere Control & Supply (ACS) - Simulates an interface to the payload 
manager software and the specific rack control manager. 
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Fire Detection and Suppressi on (FDS) - Simulates an interface to the payload 
training whenever payload procedures utilize the flight FDS system. 

Temperature & Humi dity Control (THC) - Simulates a interface to the payload 
manager software and the specific rack control manager. 

Electrical Power Sys tem (EPS) - Functions simulated include rack controller 
functions such as monitor or amps measurements, on/off status, trip status, power 
in/off, and reset commands. 

Fluid Management System fFMSt - The simulation provides the basic interface to 
support the control and monitoring necessary to support the payload training. 

Guidance. Navigatio n, and Control (GN&C) - Model simulates the onboard system 
to the extent required to support payload training. Functions simulated include 
computation of star position with respect to the SSF coordinate frame, model SSF 
orientation and acceleration using star tracker and idealized gyro models. 

internal Thermal Co ntrol (ITC> - Functions simulated provide active thermal control 
services to customer/experiments and General Lab Support Facilities in the US 
Lab. Functions simulated in the PTC include: 

1 ) Perform initialization, shutdown and system loop test. 

2) System monitor and control which includes rack flow control, pump package, 
energy acquisition and transfer and determination of system flow rates, 
including response to rack flow anomalies. 

OMA (Tier h - Provides the interface from the OMA to the element manager for 
those actions that can effect the payload operation. Only required in trainers with 
no DMS kits. 

US Lab Element Manager (Tier in - Provides the interface from the element 
manager to the rack manager for those actions that can effect the payload 
operation. Only required in trainers with no DMS kits. 

US Lab Rack Manage r (Tier llh - Provides the interface from the rack manager to 
the payload simulations for those actions that can effect the payload operations. 
Only required in trainers with no DMS kits. 

Video - This software controls the video components in the internal video system of 
the IAV simulator and can support simulation of both the intra-station and ground 
communications. 


3.1.2. Hardware Architecture 

Based on the detailed study of the three designs recommended in Volume 3 of 
the SCS Study Report, "Refined Conceptual Design Report" and on the considerations 
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discussed above in section 2.1 "SSTF Design" and 2.3 "SIB", the Local Host design 
evolved as the most suitable to meet the needs of the PTC/SCS. Consequently, it was 
selected as the initial SCS baseline for further assessment of issues surrounding the 
design and implementation of the PTC/SCS. As defined in that report for the Local 
Host design, a separate host computer is dedicated to each major trainer and facility. 
The design was formulated to: 

• use DMS kits and other SSF compatible components in all trainers 

• accept flight equivalent payload hardware and 

• software without significant modification 

• isolate and minimize the real time traffic loading on 

• the PTC/SCS LAN 

• interface directly with SSF support systems, 

• development systems, and communications systems. 

• provide for simulation of payloads, DMS, and the environment on the same 
general purpose host 

3.1. 2.1 System Design 

A top level view of the selected PTC/SCS design is shown in Figure 3.1-1. 
Details of this design are addressed in the following paragraphs. 

3.1 .2.1.1 General Description 

The architecture of the SCS baseline is distinguished by the fact that a local 
host computer with LAN interconnectivity is dedicated to each major trainer and facility. 
The following characteristics summarize the baseline Local Host design: 

• A local host is the baseline provided for each trainer and facility, with 
characteristics and performance specifically tailored to the particular type of 
trainer or facility. 

• Connectivity within a trainer is provided by the Core LAN and Payload LAN 

• Connectivity between each trainer and support facility is provided by the 
SCS LAN 

• Connectivity to external facilities is provided by telemetry and 
telecommunications 

• Trainer configuration is controlled by instructor work stations attached to the 
SCS LAN 

• A combination of both DMS supported trainers and non-DMS trainers are 
selected to provide the best engineering design and value. 

Each of the above design features are discussed in later sections of this chapter. 
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Figure 3.1-1 Local Host Overview 
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3.1 .2.1 .2 Network Architecture 

The baseline design integrates the PTC/SCS using four types of LANs: 

1) The SCS LAN which ties the separate facilities and trainers to central 
management and communications resources 

2) The Core LAN 

3) The Payload LAN within each DMS kit based trainer 

4) The local LANs within each facility that connect workstations and terminals 
to their respective file servers 

The Core LAN and Payload LAN consist of the FDDI LAN, concentrators, and 
NOS, included as part of the DMS Kit and, minimally, are functionally equivalent to 
their SSF flight counterpart. 

The traffic on the SCS LAN consists predominantly of file transfers and 
message traffic between the Session Management Functions (formerly the Training 
Session Manager), Instructor Workstations, and Trainer Host computers. A 16 Mbps 
Token Ring LAN has the capability to perform this function. 

The PTC/SCS support facilities and POIC trainers also connect to the SCS 
Network. In the case of the POIC Trainers, it should be noted that the telemetry feed is 
handled by a separate communications system and does not enter onto the SCS LAN. 

The use of local LANs within the CBT Facility and Development Facility support 
the prescribed workstation and file server configurations. The LANs support relatively 
low traffic loads of large, and acceptably queued, file transfers. Either a 16 Mbps 
Token Ring or a 10 Mbps Ethernet LAN are acceptable for this function. 

3.1 .2.2 Trainer Design 

The Consolidated, Module, and DMS kit based Part Task Trainers share the 
same essential architecture throughout the PTC/SCS design. Figure 3.1-2 diagrams 
the representative Module Trainer architecture showing the DMS Kit components and 
the allocation of the software functions discussed in Section 3.1.1 

Replication of the Space Station DMS architecture in these trainers with DMS 
Kits offers the benefits discussed in the previous studies. The approach also ensures 
that: 1) flight equivalent payloads will operate within the trainer; 2) payload models 
developed by the PTC for training are easily transportable to the SSTF; and 3) Core 
systems models developed for other Space Station requirements can be used with the 
trainers. 

Provision for generation and transmission of High Rate Science Data via a High 
Rate Link (HRL) is provided for use by any payload. Dynamic data generation up to 
100 Mbps is supported. 



US MODULE » IP PTT TRAINERS 
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3.1 .2.2.1 Host Architecture 

Each DMS kit based trainer relies on a dedicated local host -- connected to its 
SIB through its proprietary channel attachment -- to support all real time simulation 
functions not provided within the DMS-SIB complement. The Trainer Host provides 
the processing for: 1) the simulation executive governing real time functions; 2) 
configuration, setup, and initialization support to the Session Management Functions; 
3) payload, core, and environment model execution; 4) audio/video control; 5) data 
base access 6) data/event recording; 7) device stimulation and GSE control; 8) local 
diagnostics; and 9) DMS kit control. 

The Training and Simulation Executives synchronize scenario, payload model, 
core model, and data base execution in the host with DMS/OMA software execution in 
DMS Kit SDPs. Synchronization with, and control of, the DMS complement is 
mediated through the SIB. The executives monitor system status, simulation session 
status, and student actions, and allow student console and panel views to be repeated 
on the Instructor Console. Through the SIB, the Simulation Executive controls trainer 
operation including start, stop, step, freeze, sequence, and replay modes. It also 
synchronizes the interface between simulation execution and peripheral devices 
including the Audio and Video Systems and payload C&D panels. The Training 
Executive reports system configuration and simulation session status to the Session 
Manager. 

The Trainer Host may also execute payload simulations used in lieu of actual 
flight equivalent payloads when so required. Payload simulations involve the 
simulation model software developed for that payload experiment and the C&D panel 
configured accordingly. The software may be executed on the host to which the C&D 
panel is attached. If a payload normally generates video, the model based generation 
is controlled by the host using a processor attached video adapter. The host also 
controls other audio and video generated or replayed by the Audio and Video System. 

The Trainer Host communicates with the SIB and its attached DMS components 
via a proprietary high speed bus channel link. It communicates with the Training 
Session Manager and other PTC/SCS training support facilities via the SCS Network. 

The OMA and network operating system (NOS) software furnished with the 
DMS Kit are hosted on one or more DMS SDPs (or possibly in the BNIUs). Flight 
equivalent payload software may also run in SDPs or EDP-4s within other DMS 
components. The SIB provides the necessary platform and software to effect control 
and synchronization of the DMS configuration. 

3.1 .2.2.2 Model Representations 

3.1.2. 2. 2.1 Pavload Representation 

The payload representations consist of either the flight equivalent payload 
hardware and software or a software payload model and associated control and 
display hardware. The flight equivalent article includes the DMS compatible 
instrument, a flight equivalent Control and Display panel, and associated flight 
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equivalent software The software payload models consist of software that runs, under 
the simulation executive, either on the trainer host or in a DMS component processor. 

Flight Equivalent Payload 

The flight equivalent payload consists of rack mounted or attached instrument 
chassis, an integral C&D panel, application software, and perhaps peripheral 
equipment. The payload may also utilize associated lab facility hardware provided to 
support related experiments. 

Flight equivalent payloads connect to the DMS through an MDM, NIU, or a BIA. 

3.1.2.2.2.2 Pavload Stimulation 

Flight equivalent payloads are stimulated through effects experienced in orbit. 
This stimulation includes direct sensor activation, effector feedback, signal injection, 
and external forces to emulate the control and ambient effects on the experiment of the 
space station's environment. The payload stimulator is an intelligent controller 
receiving data from the Core and environment models. The stimulator connects to the 
host I/O port and to the flight equivalent hardware directly and/or through the DMS 
Local Bus. Within each trainer, the payload stimulators may also be responsible for 
controlling or emulating some of the necessary GSE services to sustain the payload. 

Where flight equivalent payloads are employed, a payload stimulator is 
required to provide sensor excitation and other ambient effects to the payload that 
would normally occur In flight. The stimulator is driven by simulation models and data 
bases which represent the Space Station environment and crew actions. The payload 
stimulators represent with some approximation those stimuli critically affecting payload 
operation and performance. 

For control purposes, the payload stimulator can be integrated into a trainer 
using three different interfaces such that: 

• A payload stimulator connects to a trainer host directly using standard I/O 
port (RS232 or SCSI). 

• A payload stimulator attaches to the DMS Local Bus (and connects to the 
Trainer Host through the SIB). 

• A payload stimulator attaches with a processor based controller and network 
interface directly to the trainer's network (Payload LAN, or Trainer LAN - if 
non-DMS trainer). 


3.1 .2.2.2. 3 Pavload Panels 

The payload C&D panels associated with individual experiments are functional 
equivalents of flight hardware positioned realistically in a trainer's lab mockup. Two 
panel types may be utilized: 1) (normally) a hardware replication of the flight payload 
panel; and 2) a generic reconfigurable terminal system i.e. a "virtual panel". These 
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panels are generally connected directly to the host. In addition to the panels, the SCS 
baseline supports other experiment devices and associated lab support equipment 
furnished within the physical lab mockup through the SIB and MDMs. 

3.1.2.2.2.4 Core Systems R epresentation 

Core systems are represented in two ways: one as simulation models running 
on the Trainer Host and, for other functions, as flight equivalent Core software running 
on the Core DMS SDPs from DMS kits. For purposes of PTC/SCS baseline design, 
Core systems are treated as representing all space station systems that affect payload 
operations or performance, other than those encompassed by the payload DMS 
representation. Environment models and data bases to represent the dynamic space 
and space station environments are also included in the Core systems category. 

The baseline C&T model provides formatted uplink/downlink communications 
containing SSF data from the: 1) Payload LAN; 2) Core systems LAN; 3) payload High 
Rate Link; and 4) audio/video sources. Payload LAN data and High Rate Link data 
can be obtained from both actual flight equivalent payloads and payload simulation 
models. The C&T model uses dedicated hardware to generate the telemetry data 
stream necessary to feed the POIC Trainers and the POIC. 

This C&T telemetry system processor/controller is shared among the lab 
trainers through a patch panel which routes one trainer's C&T-bound output to the 
processor/controller. The output of the C&T is an SSF compatible telemetry data 
stream that can be received by the POIC. The simulator inputs to the C&T include 
HRL, payload LAN, Core LAN, and host I/O feeds of science and command/status 
data. The C&T implementation also supports SSF audio/video communication 
streams. The C&T implementation will support receipt of commands from the POIC. 

3.1 .2. 2.2.5 Crew Int erface Representation 

The two primary interfaces for monitoring and control of the payloads are the 
rack mounted experiment's attached C&D panel and the lab's multipurpose 
application console (MPAC). Additional payload features such as mechanical controls 
are considered part of the lab-payload physical mockup and involve minimal 
interfacing to the SCS. 

3. 1.2.2. 2.5. 1 C&D Panels 

The C&D panel consists of switches and indicators that provide payload control 
and display of information. When flight equivalent payloads are used, the associated 
C&D panel is integral to the hardware. Alternatively, when payloads are simulated 
with software models, the associated C&D panel appears in two versions. One is a 
close replication of the actual panel hardware used on the flight payload. This is a 
custom designed piece of hardware dedicated to a particular payload experiment. 

The other option uses a "virtual C&D panel" incorporating a high resolution 
touch sensitive graphic display and appropriate I/O interfaces to achieve a functionally 
accurate representation of the actual flight panel. The virtual panel can quickly be 



TRW-SCS-90-XT2 Baseline Architecture 36 


reconfigured (re-programmed) to represent the control and display elements making 
up any flight payload experiment panel. 

3.1. 2.2.2. 5.2 Crew Console - Multipurpose Application Consoles (MPACs) 

The basic fixed MPAC currently planned for the SSF is implemented within the 
DMS kit based trainer designs using the DMS Kit supplied flight equivalent MPACs 
attached to the Payload LAN. Representation of the DMS kit supplied portable MPAC 
(P-MPAC) is similarly provided with a DMS Local Bus connection. The Module 
Trainers have been configured with two crew consoles; the Consolidated Trainer with 
two consoles in the US Lab and one each in the JEM Lab and Columbus Lab; and 
one console in each Part Task Trainer. 

3.1 .2. 2.2.6 Audio/Video Systems Representation 

The Audio and Video Systems' capabilities accommodate onboard space 
station lab internal communications and CCTV, audio communications with the 
ground, payload generated video, and computer generated imagery to simulate visual 
scenes and events associated with flight payload operations (such as viewing a star 
field). Internal PTC facility intercom is not specified as part of the PTC/SCS baseline in 
this document. 

Audio/Video System Implementation 

Where necessary, the audio and video systems are interfaced to the C&T 
portion of the Core systems representation to allow audio and video data to be 
formatted and merged into a trainer's telemetry data stream. High Rate Link data 
streams are assumed to be pre-formatted and to interface directly from the payload 
representation to the C&T processor/controller. 

The audio and video systems are implemented using standard intercom 
stations, CCTV cameras, tape recorders, and optical disks under computer control. 
Additionally, computer generated graphic imagery is provided by coprocessors or 
peripheral processors connecting to the trainer host. 

Video is generated dynamically in response to real time Core, environment and 
crew interactions. Live (NTSC) video may be mixed with any generated source in real 
time. Fidelity of the Payload video is to be rendered computer generated imagery plus 
NTSC. 

3.1 .2.2.3 DMS Components 

The flight equivalent DMS hardware and software components used to 
implement baseline DMS Kit based trainers are described in Section 2.2. DMS 
software including the Operations Management Application (OMA), Network Operating 
System (NOS), and the DMS Standard Services are executed in the DMS SDP. The 
DMS components support the connection of flight equivalent payloads to the DMS. It 
is assumed and has been depicted in Figure 3.1-2, that flight equivalent payloads 
interface to the DMS through an MDM. Provided that the payload instrument is 
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equipped with other interface capabilities such as a BIA or NIU, the trainer design will 
also accommodate these alternative modes of connection. 

3.1 .2.2.4 Trainer Connectivity 

Trainer connectivity is implemented in varying degrees throughout the Local 
Host Design. The greatest connectivity (U.S. lab module to IP modules) exists within 
the Consolidated Trainer. All trainers are interconnected only by the SCS LAN which, 
in this design, is intended to carry a minimal amount of real time simulation traffic. 

3.1 .2.2. 4.1 Consolidated Trainer 

The Consolidated Trainer has three means of connectivity across its three 
constituent labs: 1) Core and Payload LANs; 2) common Timing Generation System 
and Distribution Bus (TDB); and 3) common Core models. At present, the nature of 
the LANs to be employed in the Columbus and JEM labs is not known. The DMS Kits 
incorporate gateways between the US lab and the other labs. If the Payload and Core 
LANs of the Columbus and JEM labs are compatible with the OSI layers 1 and 2 
adopted by the FDDI protocol, the gateways may be replaced with bridges. 

The Consolidated trainer relies on a common Simulation Executive hosted on a 
single computer to supervise all three labs. The computer hosts all payload models. 
Generation of the trainer’s audio and video for the labs is also under the control of this 
host. The Columbus and JEM labs are connected to the host through an 
undetermined interface identified in the figures (3.1-1 and 3.1-2) as a Trainer l/F. 

3.1.2.2.4.2 Other Trainers 

The Module Trainers and Part Task Trainers operate independently and are 
only interconnected through the SCS LAN. Each trainer relies on a dedicated LAN for 
primary connection of its internal components. In addition to the component 
connectivity provided by the payload LAN for all trainers the SIB adds additional 
connection paths to the DMS kit based trainers. 

3.1 .2.3 Support Facilities 

The support facilities include the Development Facility, External PTC 
Interfaces, POIC Trainers, IT&V Facility, CBT Stations, Training Session Manager, and 
central Instructor Stations. A top level view of the facilities architecture is presented in 
Figure 3.1-1 and a more detailed hardware and software description in Figure 3.1-2. 

3.1 .2.3.1 Development Facility 

Since it is expected that a large percentage of the payload experiments 
installed in a trainer will be software simulation models, rather than flight equivalent 
payload hardware and software, and that at least 50% of the software models will be 
developed on the SCS, a substantial SCS Development Facility is required. The 
facility has been designed to support on the order of 100 concurrent users performing 
a mix of software development tasks without impinging on the SCS LAN. 
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The facility connects workstations and terminals (diskless workstations) to dual 
file servers via a local LAN. The diskless workstations are economical and will support 
the development function. The file servers provide common access to central code 
libraries, data dictionaries, batch job facilities, and configuration management tools. 
The workstations support the bulk of program design, code generation, compilation, 
and local configuration management. The dual file servers also provide the 
computational resource for ASCII and graphics terminals (diskless workstations) 
attached to the local LAN through a terminal server. These terminals support source 
code editing, documentation authoring, and testing tasks, as well as batch job 
submission. The file servers connect to the SCS LAN to permit developed software to 
be downloaded to the PTC/SCS trainers and other facilities. 

The documentation system is implemented with COTS publishing software 
running on a dedicated host. 

3.1. 2.3.2 External Interfaces 

The baseline will provides a real time interface to the POIC. This interface 
allows uplink/downlink data to be exchanged between the SCS and the POIC. This 
FDDI network provides a throughput consistent with other FDDI systems in the SCS. 
Improved FDDI, or multiple LANs, are expected to increase the network capacity 
beyond 100 Mbps to 300 Mbps. 

Other facility interfaces will allow file transfers between the MPS, SSTF, and the 
Pis. The interfaces are implemented as gateways to appropriate wide area networks 
(WANs). The gateway host resides on the SCS LAN. Interfaces that must support full 
telemetry data streams are implemented with the host and an attached I/O processor. 

3.1 .2.3.3 POIC Trainers 

The Payload Operations Integration Center (POIC) Trainers operate 
independently or in synchronization with lab trainers. Each POIC Trainer consist of a 
host processor and two workstations sharing the SCS LAN. The workstations serve as 
ground personnel stations. Instructor stations are located on the SCS LAN and are 
shared with other SCS trainers. The POIC trainer is connected to the SCS LAN and to 
an interface for the telemetry data stream. When this data stream is of moderate (100 
Mbps per second) bandwidth, it may contain simulated or actual DMS Payload LAN 
data and High Rate Link data. Full capacity dynamic downlink data streams, however, 
require the telemetry system processor/controller which is linked to a comparable C&T 
processor fed by one of the PTC/SCS lab trainers. Audio and video signals are 
represented realistically in the POIC trainers with feeds from the baseline PTC/SCS 
Audio and Video System. 

3.1. 2.3.4 IT&V Facility 

The IT&V Facility is used to integrate and validate, within the PTC/SCS lab 
trainer environment, the: 1) payload simulation models; 2) SSF systems and 
environment models; 3) flight equivalent hardware and software units; and 4) C&D 
panels. These elements are operationally tested within the DMS, Core, C&T, and 
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control aspects of the simulator configuration. LAN and bus monitoring capabilities 
and processor breakpoint capabilities are implemented within the facility using the SIB 
or comparable utilities. The architecture of the IT&V Facility is essentially identical to 
the Module Trainer architecture. The facility connection to the SCS LAN permits 
software modules to be downloaded from the Development Facility. 

3.1 .2.3.5 CBT Stations and Facility 

The CBT Stations consist of interactive graphic, video, and audio capabilities 
implemented on a workstation running customized courseware. The facility consists of 
several CBT Stations connected to a file server over a local LAN. The CBT file server 
is connected to the SCS LAN for downloading software and courseware from the 
Development Facility. Provisions for local removable media including optical disk, 
video tape, and magnetic disk are implemented in the baseline. 

3.1 .2.4 Simulation Control and Monitoring 

3.1 .2.4.1 Session Management Function (SMF) 

The Session Management Function [formerly known as the Training Session 
Manager (TSM)] operates as a high level system executive residing on a single host 
attached to the SCS LAN. The SMF communicates directly with the simulation 
executive programs residing on the dedicated trainer hosts. The SMF controls access 
to the trainers on the SCS LAN and mediates all file transfers and message traffic. 
While most functions like setup and initialization precede simulation session running, 
real time responsibilities do exist including supervision of Instructor Station requests. 
The Session Management Function and its host are responsible for external interface 
communications with other facilities. 

3.1 .2.4.2 Instructor Stations 

The Instructor Stations are attached to the SCS LAN and communicate with the 
individual trainers through the training executives residing on the trainer hosts. Direct 
access to the training executives is granted to monitor status information and replicate 
the views appearing on the students’ crew consoles and C&D panels. The IOS permit 
control of training scripts and scenarios. The stations are implemented as 
workstations with interfaces to the Audio and Video Systems and are represented in 
Figure 3.1-1 and 3.1-2. 
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3.2 Cost Drivers 

The implementation requirements and utility of the baseline PTC/SCS design 
are examined in this chapter in the context of a number of cost drivers. These cost 
drivers, concerning critical function and design alternatives for implementing the 
PTC/SCS, are examined in detail with particular regard to performance versus cost. 
This chapter provides the basis for the determination of the solutions presented in 
chapter 4. 

The arrangement of this chapter is as follows: Each of the cost drivers is 
examined as a set of options, design alternatives, or, in some cases, major 
parameters. There is a discussion of the impact of the cost driver under four major 
headings: Training, System, Cost, and Comparison. The ramifications of the options 
on the PTC/SCS training provided are discussed in the Training section, the impacts 
on the PTC/SCS system design for each of the cost drivers are considered in the 
System section, the cost impacts are discussed in the Cost section and a summary 
comparison/analysis is given in the Comparison section. 

The Training sections discuss the impact and implications of selecting each of 
the cost driver options on the fidelity, type, or amount of training. 

The System portion of the SCS includes all equipment and software 
representing the SSF, ground and environment elements, other real time simulation 
training functions, the hardware and software supporting non-real time simulation 
training functions such as initialization, reconfiguration, record keeping, and executive 
control of instruction and external communications links; and support functions such as 
model development and test, scenario development and management, and CBT. 

Generally, the table in the Comparison section of each cost driver issue selects 
distinctive options and contrasts the differences in their hardware and software 
makeup. In some cases, where it is more meaningful, the Comparison section simply 
summarizes the major effects of the options. The "fixed" requirements refer to those 
system and trainer components that comprise the completed PTC/SCS before specific 
payloads are installed. The "incremental" requirements refer to hardware and 
software components that must be developed or modified to implement training on a 
particular SSF increment. Primarily, the incremental change consists of introducing a 
set of new payloads. Where cost is based on a "unit" trainer, that is taken to mean the 
U.S. Lab module trainer - with a "shipset" of 43 payloads (24 concurrently active) - 
unless noted otherwise. 

The comparison table identifies option requirements which differentially affect 
PTC/SCS and training implementation costs, not life cycle costs such as SCS 
maintenance and expansion. If these factors are impacted differentially by the options, 
the effect is noted in the table in the Comparison section. 

Frequently, the unique components used to implement an option directly 
depend on other system/trainer components that must be present for the 
implementation to work. When these secondary or derived requirements differ 
between the options, they are included in the Comparison tables. 
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The assessments made in this section are based on overall PTC/SCS 
implementation cost considerations. Final selection of the best option under any 
particular cost driver should consider other factors such as relative risk and impact to 
implementation schedules. The System's potential to accommodate changes in PTC 
mission requirements should also be considered. 

Computer platform classes are referenced in the Comparison tables by a two 
letter code. See Figure 3.2-1 below for an explanation of these codes. Codes do not 
necessarily imply implementation or use of a specific platform. Derivation of detailed 
performance data and the assumptions made in this process is documented in 
Appendix A. This Appendix is based on the work documented in the SCS Study 
Report - Volume 3, the "Refined Conceptual Design Report", 31 October 1989, and all 
the design work done by the SCS Study team during 1990. 


ID 

DESCRIPTION 

PERFORMAN 
CE (in MIPS) 


EXAMPLE 

SC 

Super Computer 

100-1000 

mm 


MF 

Main Frame 

20-120 

$110 

Amdahl 5990 

MS 

Mini-Super 

50-200 


Convex C240 | 

SM 

Super-Mini 

30-80 


DEC 9000 

WS 

Work Station (Engineering) 

6-30 

mm 

DECstation 5000 

WG 

Work Station (Graphics) 

6-30 


SGI 4D/240 GTXB 

RS 

RISC (Reduced Instruction Set 
Computing) Station 

5-27.5 

Hi 

IBM System 6000 

PC 

Personal Computer (Standard) 

0.5-5 

HU 

IBM AT 

MC 

Mini-Computer 

10-40 

$70 

DEC 8830 


FIGURE 3.2-1 REFERENCE COMPUTER CHARACTERISTICS AND 

PERFORMANCE 
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3.2.1 Type of C&D Panel Crew Interface: 

a) custom hardware panel 

b) virtual panel 


Training: 

Custom hardware C&D panels will provide the highest fidelity training possible 
in a non-orbital environment. 

Virtual panels are representations of the actual C&D panels drawn on a 
computer screen with a touch screen overlaid. Trainees can touch the drawing of a 
button or dial to interact with the panels. This technology has been investigated as 
part of the SCS Study, and panels that look like photographs of actual control panels 
are currently available off the shelf. The pictures react to touch just like the real 
panels, e.g. when you touch a toggle switch or push button picture, the switch or button 
is redrawn in real time in the flipped or pushed position. The training provided by 
virtual panels will never be as high a fidelity as custom hardware panels, but would be 
greater than medium fidelity. This might well be sufficient for some or all of the part 
task training for payloads. This technology is currently being used for training in part 
task training on avionics and other real time control simulations. Some training 
objectives may not be well served by virtual panels when manual dexterity or depth 
perception are important aspects of the crew tasks. 

System: 

The custom hardware panel, whether driven by the payload instrument or by a 
software model, will require more I/O processing (in hardware and software) than a 
virtual panel which has onboard intelligence to provide standard communications 
protocol over a SCSI or similar link. 

Virtual panels would provide rapid reconfiguration to any increment since the 
C&D descriptions would all be data driven. The ability to quickly configure a module 
trainer to a specified increment could mean less module trainers may be required, i.e. 
one US Lab Module instead of two. Quick reconfiguration would aid in scheduling 
training for currently training increments. Virtual panels will require additional disk 
storage for reconfiguration downloads. Development utilities for the virtual panels 
such as object oriented shells for rapid software development can minimize PTC 
development resources and labor. 

Cost: 


Custom hardware C&D panels will likely only be provided by Pis when they are 
providing the complete flight equivalent payload instrument. The flight equivalent 
panel is also a custom construction which may or may not be provided by the PI. Due 
to manufacturing, hardware configuration management, and installation time, 
development cost can be expected to be at least an order of magnitude greater than 
that needed for constructing virtual panels. Estimates based on PCTC experience are; 
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120 hours for design and manufacture; 21 hours for documentation; 4 hours for CM, 8 
hours for test; and 4 hours for installation; for a total of 1 57 hours per panel. 

If custom hardware panels are not provided by the Pis, development of custom 
C&D panels with some level of functionality will require specialized development, 
manufacturing, and test facilities at the PTC. 

The cost of a display terminal for each payload in the shipset (e.g., 43 in the 
U S lab module trainer) is amortized over the number of full change-outs of payload 
shipsets over the life of SSF. (Thus, if 15% of the payloads are changed out in every 
90 day increment for 30 years, then final panel hardware cost per payload is the 
original shipset cost divided by 18 full change-outs). 

The bottom line is the difference in per unit cost of the custom item versus the 
per unit virtual panel development time plus the per unit share of the initial cost of the 
PTC/SCS virtual panel development platform/shell and the fixed number of delivery 
platforms amortized over the total number of payloads simulated over the life of SSF 
(e.g., approximately 600 based on 20 per year for 30 years). 

Engineering estimates indicate that a well designed virtual panel shell will 
permit development and test of a payload panel in about 40 man-hours. 


Comparison: 



1 HARDWARE REQUIREMENTS 

SOFTWARE REQUIREMENTS I 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

Custom 

H/W 

panel 

1 MDM for every 
F/E P/L + 1 
CAMAC C&D l/F 
for each rack + 1 
CAD/CAM WS + 
a panel manu- 
facturing facility 

Custom panel for 
each P/L (157 
labor hours + 
material) 

Custom panel & 
F/E C&D l/F 
programs + 
CAD/CAM 
mechanical & 
electronic S/W 

PI or PTC 
program for each 
C&D panel 

(b) 

virtual 

panel 

1 virtual panel 
WSs of 5 
MIPS*** 
with 4 monitors 
per rack + 1 
develop WS of 8 
MIPS**** 

None (other than 
P/L specs from 
Pis) 

Development 

toolset 

40 labor hours 
per P/L 


*** Virtual panel delivery workstation is per estimate in Section 2.6 of Appendix 
A. 

**** Development workstation for virtual panels is comparable to WS in Section 
2.21 of Appendix A, supporting up to 1 2 new payloads in 90 days 
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3.2.2 Type of MPAC Crew Interface : 

a) flight equivalent MPAC 

b) simulated MPAC 


Training: 

Flight equivalent MPACs will provide the highest fidelity training possible in a 
non-orbital environment. 

Simulated MPACs could range in fidelity from low - a COTS PS/2; to medium - 
an 80386 WS with a single display screen; to high - a complete functional copy of the 
flight MPAC (per the Training FCD, a "II A" fidelity simulator). While the low and 
medium fidelity MPACs would be useful, the fidelity for payload training at the PTC is 
required to be high, and thus the MPAC must look (have the same number and type of 
screens, hand controllers, and keyboards as a real MPAC), and these must be 
functionally (same colors, same menus, same timing) like real MPACs. This means 
option "b" considered here is a high fidelity MPAC simulator. 

System; 

The higher the MPAC fidelity, the greater the communications load will be on 
the SCS Trainer LAN. 

If the MPAC is simulated, a common platform could be used to implement both 
the MPAC and the Instructor Station, resulting in more flexibility for reconfiguration and 
expansion. 

Cost: 

Flight equivalent MPACs are currently projected to be expensive ($159K each) 
relative to COTS hardware - workstations and associated peripheral devices (extra 
screens and hand controllers). Software necessary to emulate/simulate the MPAC 
look and functions, however, will require custom development if a COTS workstation is 

used 


A high fidelity MPAC simulator (option b) would require three 15" color flat panel 
displays which can window NTSC video, two hand controllers, one keyboard with keys 
that match the flight MPAC, and an 80386 workstation to drive these peripherals. The 
color flat panel displays to be used are not yet commercially available. They are being 
developed under a joint IBM/Toshiba effort. The DMS software would have to be 
modified to work on the workstation, or software written to simulate the DMS software 
(OS/Ada Run Time Environment, Standard Services, Data Storage and Retrieval, User 
Support Environment, System Management, and MODB Manager). Since the cost of 
this DMS software simulation would be amortized over a small number of units, and 
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the DMS software would be GFE to the PTC, the high fidelity MPAC simulation (b) 
would cost more than the flight equivalent MPACs (a). 

For a medium fidelity MPAC simulator, a current midlevel workstation with 
graphics (15” CRT color display) plus CCTV/VCR peripherals should be sufficient 
hardware for fixed MPAC fidelity (meets training requirements). A window 
representation of the MPAC's three monitors will provide adequate "look & feel" as 
well as functional fidelity. Assuming that the initial simulation software development 
costs can be amortized over several units, the per unit cost is estimated to be roughly 
two thirds the cost of a flight equivalent MPAC. 

A low fidelity "functional only" simulation can be achieved with a PS/2 and an 
8514/A plus NTSC display for about one fourth the cost of a flight equivalent MPAC, 
not including required custom software. This is based on SCS Study Extension Task 
5 experience. 


Comparison: 



HARDWARE REQUIREMENTS ( 

SOFTWARE REQUIREMENTS j 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

F/E 

MPAC 

1 FMPAC + 1 
portable per 
DMS trainer or 
facility+ 1 
additional 
FMPAC for IT&V 

None 

F/E USE and 
other DMS 
system programs 

None 

(b) 

simula- 

tion 

1 RS of 5 MIPS” 
+ 3 flat panel 
displays +2 hand 
controllers + A-V 
components for 
each FMPAC 
representation + 
1 Lap Top per 
trainer or facility 

None 

41 K SLOC”* 
emulation 
program + 
develop, toolset 

None 


** Workstation estimate for crew interface function is based on similar designs 
(discussed further in Section 2.6, "Crew Interface Representation", of 
Appendix A) 


*** Estimate is based on the assessment that the simulator will implement 
approximately 50% of the functions of the full space station along with code 
sizes, of flight equivalent USE and SM derived from S/W sizes provided in 
DMS SRS documents. See Paragraph 3.2.6, "Use of DMS Kits" for details. 
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3.2.3 Fidelity of Payload Models: 

a) full functionality (Level 1 or 2 per the DMS ACD) 

b) black box functionality (Level 3 per the DMS ACD) 

See Appendix B for a copy of the DMS ACD Level definitions. 


Training: 

Full payload functionality would provide the highest fidelity possible non-orbital 
training. The functionality must result in discemable events with which the crew 
(trainee) may interact; otherwise the heightened functionality is meaningless for 
training. Payload model update rates must be fast enough so that the trainee sees the 
same payload response (display, light , needle move, etc.) that would be seen on the 
flight payload. 

Black box functionality, where the payload model responses might be table 
driven for example, could provide procedural training with enough fidelity to 
supplement the required high fidelity science training. Previous SCS Study work 
(Study Issues Report, 31 Oct. 1989, Issue T-6 "Fidelity of SS Experiment Simulators") 
based on SpaceLab PCTC experience clearly indicates that high fidelity payload 
simulators will be required in the PTC. 

Simulation update rates also affect the fidelity of payload simulations. The 
appropriate update rate varies with the particular payload, SSF, or ground 
function/event being represented. Simulation cycles only need to be frequent enough 
to yield realistic input/output that is tangible to the crew (trainee) and that relates to 
training objectives. 

System; 

Full payload functionality will require commensurate functionality in the 
environment models and Core models, as well as in payload stimulation and GSE 
capabilities. Full payload functionality means larger software models than those 
required for black box functionality. Larger models mean proportionately greater 
required computer CPU power (MIPS) and greater central storage space and 
download capacity for system reconfiguration and initialization. 

Full functionality has an indirect effect on operations requirements. Larger and 
more complex models means correspondingly longer development time, resulting in 
the requirement for more concurrent development and testing system capabilities. 

Slower update rates provide a savings in the total MIPS required, and may 
allow more concurrent training sessions to be hosted on the same complement of 
computers. 

Update rates have a secondary effect on system support. A potential effect is a 
larger session recording capacity (to support data logging and recovery functions). 
This increase is required since the capture and store rate must be increased to track 
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the highest simulation update rate (otherwise some short term events would be 
missed). 

Update rates cannot be assigned if DMS kits are part of the installation. The 
presence of DMS Kit components and flight equivalent software in a design limits the 
possibility of implementing and synchronizing "local" update rates that are economical. 
Thus, even though training objectives may be served with a slower rate, the presence 
of flight equivalent DMS elements may dictate faster update rates. 


C9SL 

Complexity, in general, increases directly with model fidelity. An assumption, 
based on SpaceLab experience (see Study Analysis Report, 31 October 1989, Issue 
T-1 "Scope of Payload Crew Training in the PTC") is made that a 5:1 ratio in program 
size applies to model fidelity - i.e. a fully functional model is 5 times the size of a black 
box model. In SCS Issue T-1 , it is estimated that payload model complexity spans a 
5:1 range in program size for "complex" versus "simple" models. The computational 
requirements for payload model fidelity levels vary in the same ratio. In general, 
development and revision time for model software (and PI specifications) will be in 
proportion to the complexity. Further, the simple models will demand less from other 
SSF/ground models, resulting in proportionately lower costs across all PTC simulation 
software. 

The update rate is simply a multiplier on the CPU capacity or number of 
computers required. The proportionately smaller CPU computing requirement may be 
further reduced by other potentially simpler simulation models needed to support the 
slow update rate. 

The number of payload simulation models is also a multiplier on the CPU 
capacity or number of computers required. A refinement to this direct ratio may be 
necessary since additional costs will be entailed if flight equivalent payloads present 
unique requirements for GSE services, sensor/effector stimulation, Core systems 
functions/data, and High Rate Link data connections. 

The recurring labor cost of developing and testing payload model code can be 
estimated to equal about ten man-years per model using a programming rate of 150 
SLOCs per man month. SLOCs are calculated starting with Appendix A, Section 2.4, 
"Payload Representation". The 5:1 ratio reduces the average 20,000 SLOCs per 
model to an estimate of only 4,000 lines. Consequently, software development facility 
requirements would be estimated at 3 MIPS CPU capacity plus 60 MB disk storage per 
payload model (assuming a one year payload model development cycle). 
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Comparison: 



HARDWARE REQUIREMENTS 

SOFTWARE REQUIREMENTS | 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

full 

func- 

tionality 

0.5 MIPS* on MC 
per P/L+ 33 
development 
WSs of 8 MIPS** 
each (+ PI remote 
interface as 
needed) 

None (unless P/L 
model requires 
F/E C&D panel) 

Advanced 
develop, toolset, 
hi-fi Core & 
environ, models 

20 K SLOC 
program per P/L* 

(b) 

black 

box 

func- 

tionality 

0.1 MIPS* on MC 
per P/L + 1 1 
development 
WSs of 8 
MIPS**each 

None 

Basic develop, 
toolset 

4 K SLOC 
program per P/L* 


* Based on the weighted average simple, medium, and complex, model size 
from Section 2.4.2 of Appendix A (and run at standard average update rate 
of 2 Hz) 

** Development workstation is per Section 2.21 of Appendix A. 
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3.2.4 Fidelity of Core Systems Models: 

a) flight equivalent functionality 

b) simplified functionality 


Trainers: 

Flight equivalent core models, such as might be obtained from WP02, may not 
be practical for most payload simulations. The full fidelity they provide is not 
necessarily translated in training fidelity visible to the trainee. 

Simplified functionality core models can, in most cases provide full fidelity 
training. Realistic core functions can be simulated with smaller models and far less 
overhead than using flight equivalent software. 

System: 

Flight equivalent core models would require payload models to provide a full 
core system interface. For example, to interface to electrical power, a payload 
simulation would have to model power-on current levels (Amps, Volts), current drawn 
fluctuations, power up, power down, and so on. Payload training may only require a 
model that has power on or off modeled. 

Simplified functionality core models would be smaller in size. Examples of 
functions that require only simple simulation are electrical power, fluid management, 
and the Process Materials Management System (PMMS). There might be high fidelity 
required for parts of some functions , C&T for example. But the part of C&T that is 
specific space to space communication could be omitted without degrading payload 
training. 

Core models are executed in each trainer host. A problem exists when the 
payload model is designed to support payload training, and interfaces to simplified 
functionality core models. The SSTF core models are full fidelity, and require many 
more parameters to be modeled than needed for high fidelity payload training. 

Cost: 

Flight equivalent Core system models are expected to be available. Their 
fidelity and complexity will demand complex interfaces of payload simulation software. 
Upgrading and maintenance, however, should be significantly easier than with custom 
core simulation software. Considering the limited scope of Core data needed by 
simulated or flight equivalent payloads, costs associated with acquiring, integrating, 
and driving the flight equivalent software would be greater than that for simpler models 
with selective functionality. 

Simplified functionality custom model software is an additional development 
cost over the use of flight equivalent Core system model software. If the flight 
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equivalent core models are modular enough, simplified functionality may be achieved 
by using only the required modules. 

The bottom line costs are likely to be less for simplified functionality core models 
than for the full-up system because of the expensive computers required to host the 
flight equivalent software and the high fidelity models required to accommodate this 
software. 


Comparison; 



HARDWARE R 

EQUIREMENTS 

SOFTWARE REQUIREMENTS | 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

m 

iiPiiEinm 

6 MIPS* on MC 
per trainer 

None 

49K* SLOC 
program 

None 

msm 

sun™ 

1 MIP** on RS 
per trainer 

None 

16K** SLOC 
program 

None 


* This is for flight equivalency constrained to payload important areas - for 7 
core models of 7K SLOCs each. Also see estimate and logic in Section 2.2, 
"Core Systems Representation", of Appendix A. 

** This is based on 33% of the function (and program size) at half the update 
rate of flight equivalent Option (a) 
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3.2.5 Fidelity of Environment Models: 

a) full dynamic effects 

b) simplified effects 


Trainers: 

Full dynamic effects models would provide the highest fidelity training. 
However, full dynamic effects models have little training value for the majority of 
payloads since the effects of environment models are not visible to the trainee. In the 
few payloads where the effects are visible, full dynamic effects models will be 
essential. 

Simplified effects models will be quite adequate for most payloads. 

Environment models are important only to the extent that the science dynamics 
modeled in the payload models respond to the environmental states. In some cases, 
full dynamic effects models may be required to drive flight equivalent payloads or their 
associated payloads stimulators. 

System: 

Full dynamic effects environmental models will be large and complex, which will 
require both memory and CPU processing time. 

Simplified functionality environmental models would be smaller in size, and 
require less memory and CPU processing power. There might be high fidelity 
environment models required for parts of some functions, GN&C for example. 

Environment models are executed in each trainer host. A problem exists when 
the payload model only requires simplified environment models but only complex 
models are available. The payload model may have to be made more complex to 
interface to a complex environmental model. However, if the environmental models 
are cleverly designed, only the parts needed could be selected for use, and the 
payload model could be only as complex as required for training. 


Cost: 

Some environment models may be obtained from WP01. Models providing full 
dynamic effects will only be needed to drive flight equivalent payloads. In terms of 
SLOCs, a 3:1 difference in code size is estimated to implement full versus simplified 
dynamic effects. 
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Comparison: 



HARDWARE R 

EQUIREMENTS 

SOFTWARE REQUIREMENTS f 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

full 

dynam- 

ic 

effects 

4.5 MIPS on MC* 

None 

24 K SLOC* 
program 

None 

(b) 

simpli- 

fied 

effects 

0.75 MIPS on RS 
** 

None 

8 K SLOC** 
program 

None 


* Assumes 50% more functionality than model used for module trainer 
estimated in Section 2.5, "Environment Representation", of Appendix A. 

** Simplified means 50% less functionality than full dynamic model at half the 
update rate. 
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3.2.6 Use of DMS Kits: 

a) complete in all trainers 

b) complete in module trainers 

c) partial in all trainers 

d) simulated in all trainers 


Training: 

Use of DMS Kits for training will provide the highest fidelity training possible. 
The confidence that the trainees will have in the training will also be high. The MSFC 
Payload Crew Training Complex (PCTC) provides excellent, high fidelity SpaceLab 
payload training. Still, a number of crew trainees have, on their own, made their way 
over the the MSFC SpaceLab Software Development Facility (SDF) to observe the 
flight computers, flight payload interfaces, flight support hardware, and flight software 
in action to gain further confidence in their readiness to accomplish the goals of a 
flight. The SCS Study Task 6 Technical Demonstration, given in August 1989, 
showed the potential synergism between a flight equivalent software development and 
verification facility and flight equivalent system use for training. 

Use of DMS Kits will also permit the most realistic non-orbital training with flight 
equivalent payload hardware and flight payload software. The PDRD - SSP 30000, 
Sect 4, Part 3, 3.12 Training: in 3.12.1 states, “High fidelity training systems shall have 
the capability to use flight software" and in 3.1 2. H, "Flight type hardware shall be 
utilized in ground training applications whenever: The use of such equipment would 
be more economical to the SSP than building replicas; substitute hardware cannot 
provide the required fidelity or training results". The trend for Spacelab is toward more 
use of flight equivalent hardware and software for payload training. 

Simulating DMS without the DMS Kit flight equivalent hardware and software 
would also provide high fidelity training. The best example of this type of training is the 
many aircraft cockpit flight simulators used to train pilots. The difference between the 
PTC and these aircraft simulators is that 4 to 12 of the instruments to be trained on in 
the PTC will be swapped out every few months (in each increment). This is not true in 
the aircraft flight simulators. This means the use of flight equivalent payload 
simulations has the potential to be more cost effective. Also, running payload flight 
software and flight hardware will require, for timing and electronic interfaces, the 
hardware that is essentially equivalent to an SSF DMS Kit. 

System: 

For the trainers in which complete DMS Kits are used, flight equivalent software 
will be run with appropriate interfaces to simulation software necessary to achieve a 
realistic SSF environment. This will demand more complete and higher fidelity Core 
and environment representations than for a simulated DMS. 

Complete and exclusive use of DMS kits in all trainers obviates the need to 
build any DMS simulations and provide CPU capacity to run these models. 
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Complete DMS Kits only in module trainers (Option b) means the PTTs will be 
non-DMS trainers. The DMS Kit will have to be simulated with software and hardware. 

The partial DMS implementation (Option c) involves interfacing key DMS 
components directly (no SIB) with the simulation host or sharing key DMS components 
across trainers. 

The partial DMS implementation presents a unique possibility to achieve high 
payload fidelity without complete DMS Kits. By employing only the MDMs (per 
Paragraph 3.2.8, “Use of MDMs”) and a high proportion of flight equivalent or 
comparable payload instruments, an effective partial design is possible. The MDM 
would be interfaced directly to the Trainer Host’s which would simulate all other 
necessary DMS functions. The same CPU platform, or additional networked platforms, 
would host payload models when they were employed. Corresponding C&D panels 
for these simulators could be driven through the MDM. The design would provide a 
payload simulation system that could plug directly into the SSTF’s flight equivalent 
DMS array (see Paragraph 3.2.23, "Payload Simulator Transportability to SSTF") as 
well as into the PTC's trainer hosts. Simulation functions obtained from the SIB in 
complete DMS designs would be handled by the host. The risks associated with 
partial DMS are much the same as those in Option d. 

Simulating DMS (Option d) to replace DMS Kits would require a significant 
amount of hardware and software. Since the DMS Kit design is still evolving, even the 
currently estimated amounts of software and hardware may not be enough to insure 
that flight equivalent payload software and flight equivalent hardware will run, i.e. there 
is some risk that further hardware and/or software would be needed to get the job 
done. In addition, the IP Data Systems must also be simulated. Finally, any flight 
software that could be run on DMS Kits would have to be simulated, e.g. C&T. 

Cost: 

The cost differential between certified flight equivalent DMS components 
(Option a) and generic COTS hardware of comparable performance is likely to be 
greater than 5:1. Development of custom software used with COTS hardware to 
simulate the DMS (Option d),on the other hand, will add programming labor of 
approximately 206,500 SLOCs, or about 115 man-years, plus any subsequent 
revisions during the 30 year life cycle owing to an SSF change in design or 
functionality. The SLOC estimates are based on the expectation that the simulation 
code size will be about the same size as the flight equivalent DMS software estimates 
(see note below). The labor estimate reflects a coding rate of 150 SLOC per man 
month. 

The cost of Option b includes both DMS Kits and DMS simulation software for 
the non-DMS Kit PTTs. 

Option c would combine DMS Kit components and COTS hardware and 
software costs. The cost of integrating, testing, and making the small amount of 
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software estimated work could be very high based on the SCS Study Task 5 effort. 
This approach looks attractive, but could also be the most expensive. 


Simulating DMS (Option d) means not using ITVE (see paragraph 3.2.22 "Use 
of SSE/ITVE Tools", since ITVE is designed to operate with DMS Kits. 

Comparison: 



HARDWARE REQUIREMEN T [ 

SOFTWARE REQUIREMENTS 1 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 
com- 
plete in 
all 

trainers 

1 sized DMS Kit* 
complete (+ SIB) 
per concurrent 
trainer 

None 

F/E Programs 
including OMA 

None 

(b) 
com- 
plete in 
module 
trainers 

1 sized DMS Kit* 
complete (+ SIB) 
per concurrent 
trainer 

None 

F/E Programs 
including OMA + 
DMS Sim S/W for 
PTTs 

None 

(c) 

partial 
in all 
trainers 

1 partial DMS Kit 
(- SIB) per 
concurrent trainer 

None 

Modified F/E 
Programs 
including OMA + 
10 KSLOC 
program 

None 

(d) 

simu- 
lated in 
all 

trainers 

1 sized COTS 
complement** 
per concurrent 
trainer 

None 

81 .5 KSLOC"” 
DMS simulation 
programs + 125 K 
SLOC SIB, TGU, 
MDM, & GSE sim 
+Flt S/W Sim 

J££D 

None 


A complete DMS kit includes one or more of the following items: SDP, 
SDDU, RC, HRL, MDMs, MPACs, TGU, MSU, PP, SC, BNIU, BR, and 
several different interfaces and monitors - see DMS Kits Requirements and 
Allocations Data Base Update, NASA-MSFC, for detailed listing of different 
kit configurations. 


** Consisting of hardware listed below 

• 29 Host p Computers (equivalent to 80386 in speed and power) for SDP 
simulation 

• 27 PS/2-80S + peripherals for MPAC simulation 

• 56 Flight Equivalent MDM l/F cards (40% F/E P/Ls assumed) 
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*** Simulation of F/E DMS at 100% of functionality and code sizes from DMS 
Software Requirements Specs (SRS) documents total calculated as 
follows: 


Caution & Warning .2 K 

Network O/S 20.5 K 

OMA 25.0 K 

O/S ADA Run Time Environment 1 1 .5 K 

Standard Services 4.3 K 

Data Storage And Retrieval 1.5 K 

User Support Environment 5.9 K 

System Manager 7.1 K 

MODB Manager 5.7 K 


Total 81.5 K 


These numbers were obtained by translating from the KBytes given in the 
Software Requirements Specs (SRS) documents using 3.5 Bytes/DEMI and 
10 DEMIs per SLOC. 

Size of the other functions is estimated, based on required functionality and 
experience, as follows: 


SIB ~50 K 

MDM ~50 K 

TGU & TD ~5 K 

GSE ~2Q_K 

Total 125 K 
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3.2.7 SIB's Interface to Host Computer: 

a) proprietary channel attach 

b) LAN 


Training: 

The type of host interface would be transparent to the trainee. However, the 
additional flexibility provided by a LAN potentially provides improved training since it 
would allow more options in trainer configurations. 

System: 

The proprietary channel attach will preclude the possibility of sharing hosts 
across DMS trainers: i.e., a particular host will be hardwired to a DMS trainer. This 
choice significantly restricts reconfiguration options and potentially increases the total 
number of hosts needed. One host per trainer will be required. 

The LAN interface would permit the connection of several hosts to a SIB, 
enabling each DMS kit to be driven by a different host or shared across hosts. The 
arrangement would provide considerable flexibility in quickly forming different host 
configurations to meet training needs. One host per concurrent trainer session would 
be required. The high rate throughput of the trainer host to the SCS network and the 
complexity of multiplexing concurrent host sessions to the SIB are potential problems 
with this approach. Note that the required throughput of 53.6 Mbits per second [ref 
DMS Kit CEI Spec ] is within FDDI network bounds. 

The LAN interface also allows optimum choice of type of CPU platform to be 
used since a host with the proper interface can be attached to the LAN. A direct 
SIB/host interface is constrained by the proprietary point-to-point interface. 

Note that to capitalize on the potential host reconfigurability, the Session 
Management Function will need additional functionality to effect and manage cross- 
trainer interconnections. Further, if a SIB is shared among trainers, additional systems 
level software is necessary to enable trainer configuration and arbitration control. 

Cost: 


Option (a), "proprietary channel attach" would be substantially more expensive 
than the "LAN" option. Estimates are that the proprietary channel interface along with 
the supporting circuitry to other components of the system covered exceed the cost of 
the LAN option for the PTC/SCS. This option's principal expense comes from the 
direct attachment of the host to each trainer. On the other hand, this would allow the 
use of a low cost SCS LAN (Ethernet) for interhost connections, since the high speed 
transfers would be off the LAN. Because of the distance between host and trainer 
within the PTC, it is necessary to include fiber optic components in the proprietary 
SIB/host channel attachment. This further adds to the cost. 
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Option (b), "LAN" connection can result in significant savings primarily because 
the number of hosts needed is equal to the number of concurrent training sessions - a 
result of allowing a given host to connect to any trainer. However, the requirement for 
high data rate transfers between host and trainer results in a far more expensive LAN 
(FDDI based or similar). 


Comparison; 


HARDWARE REQUIREMENTS 


SOFTWARE REQUIREMENTS 


FIXED 


INCREMENTAL 


FIXED 


INCREMENTAL 


" (a) 
propr. 
channel 
attach 


Propr. Channel 
Interface per 
trainer + Fiber 
Optic extensions 


None 


(b) COTS NIU/BIA 

LAN per trainer + high 

speed SCS LAN 


None 


Associated Propr. None 
Channel to SIB 
Interface 
Program (ITVE 

provided) 

Associated LAN None 
to SIB Interface 
Programs 
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3.2.8 Use of MDMs: 

a) use MDMs 

b) partially simulate MDMs with software 

c) fully simulate MDMs with software and hardware (capability 
comparable to SSF DMS Kit MDM capability) 


Training; 

Flight payload software may be designed to run on, and use facilities of, the 
MDM. Use of MDMs will permit this payload flight software to be used for training. 
MDMs will also provide the capability to use flight equivalent payloads for training at 
the PTC. Currently at the Spacelab PCTC, work is being done to increase the 
available amount of this type of training because experience has shown it is valuable. 

As demonstrated by the current PCTC configuration, MDMs can be simulated. 
However, neither flight equivalent payloads nor payload flight software are supported 
by the PCTC equivalent MDM simulation. 

System; 

Flight equivalent payload instruments will plug directty into a MDM. Some of 
the payloads flight software will run on the MDMs. 

For payloads simulated with software that runs in the SCS Host, MDMs are 
easily simulated in software (option b). 

To support flight equivalent payloads with simulated MDMs (option c), sufficient 
COTS I/O hardware & software must be added to handle signals and timing necessary 
to satisfy flight equivalent payload demands. The same type of CPU and internal 
communications available within a MDM must be duplicated to be able to execute 
payload flight software. 

Cost; 

MDMs are expensive (currently $239K each). 

Simulating them in software is simple, but does not support the use of either 
flight equivalent payloads or payload flight software for training. 

The cost differential between flight equivalent DMS MDMs and generic COTS 
hardware of comparable performance is likely to be greater than 5;1 . However, COTS 
hardware will not have the same interface as a MDM, so to duplicate the MDM 
interface, custom hardware would probably have to be built. Also, development of 
custom software, used with COTS or custom hardware to simulate the MDM, could add 
significant programming labor. 
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HARDWARE REQUIREMENTS I SOFTWARE REQUIREMENTS 



FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

use 

DMS 

MDMs 

1 DMS MDM tor 
every F/E P/L in 
trainer's shipset 

F/E P/Ls 

F/E MDM 
programs (+ 
support for Pi’s 
user code) 

F/E P/L S/W and 
Install 

appropriate DMS 
Kit S/W updates 

(b) 

partially 

simulate 

0.2 MIPS per 
trainer on MC 

None 

2 K SLOC MDM 
simulation 

Update MDM 
simulation when 
MDM design or 
functionality 
changes 

(c) 

Fully 

simulate 

1 COTS or 
custom MDM 
processor + 
memory +custom 
I/O board per 
every F/E P/L 

F/E P/Ls 

50 K SLOC MDM 
simulation and 
I/O processing 
S/W 

F/E P/L S/W and 
Update MDM 
simulation when 
MDM design or 
functionality 
changes 
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3.2.9 Use of OMGA 


a) flight equivalent 

b) simulate 


Training; 

A flight equivalent OMGA would provide a more realistic simulation of ground 
operation activities over a custom simulation. Paragraph 3.2.6, "Use of DMS Kits" and 
Paragraph 3.2.4, "Fidelity of Core Systems Models" discuss issues related to OMGA 

use. 

System; 

Additional hardware would be needed since using flight equivalent OMGA 
requires an equivalent to the operational ground based computer to host this software. 
The POIC should provide this. 

Development of unique OMGA simulations will entail a significant, one-time, 
development effort requiring adequate development and testing system capacity. 

Whether OMGA is flight equivalent or simulated, it will be necessary to drive this 
function in order to produce ground control exchanges. This necessity can be met with 
either an instructor or trainee performing the role of the ground personnel, or an "auto- 
controller" model which realistically simulates the behavior of ground operations 
personnel. 

QqsL 


Software estimates for the OMGA are not yet available, but we estimate that the 
OMGA will be at least 50K (twice the size of the OMA). 

An OMGA simulation, not including MPS, is estimated to be 50% of that sized 
for the operational OMGA, or 25K. The "50%" is based on the hypothesis that the 
simulated function will need no more than 50% of the functionality of the flight article. 


Comparison; 



HARDWARE REQUIREMENTS 

SOFTWARE REQUIREMENTS | 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) “1 
F/E 


None 

50K SLOC F/E 
OMGA* 

None 

(b) 

simul- 

ated 

2 MIPS on RS "* 
per trainer 

None 

25K SLOC 
program** 

None 


** Based on size for simulated ground control function from Section 2.8, "POIC 
- DMS Interface", in Appendix A. 
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3.2.10 Concurrent Independent Training Sessions 

a) 2 US Lab Modules, 0 US Lab PTTs, 3 LoFi Sims, 1 ESA or 1 

JEM PTT _ 

b) 2 US Lab Modules, 3 US Lab PTTs, 1 ESA or JEM PTT 

c) 2 US Lab Modules, 3 US Lab PTTs, 1 ESA, 1 JEM PTT 

Training; 

Independent training sessions are defined as training one or more trainees on a 
specific timeline or On-board Short Term Plan (OSTP) for one or more payloads. 

Extensive analysis by TRW, NASA training, and Boeing shows that 5 
independent training sessions (or scenarios) are required to support SSF operation. 
These involve concurrently operating trainers as shown in option (c) since NASA 
training personnel have as a requirement a limited consolidated increment training 
where one or both of the IP PTTs work in concert with the US Lab Module Trainer. 

Option (b) represents the current CBR baseline.which provides 6 independent 
scenarios for training, but no consolidated increment training. 

Option (a) represents a approach where early training is procedural at the PTC 
using LoFi simulations with all the high fidelity science training being done at PI sites. 

System; 

The number of concurrent trainer sessions has a significant effect on the system 
resources. The number of host computers and DMS Kits is obviously affected. Also, 
system level resources must be sized in direct proportion to the number of concurrent 
sessions. These resources include the multiplex speed of the real-time portion of the 
Session Management Function, bandwidth for the real-time portion of the PTC/SCS 
LAN, the number of instructor stations, and the storage speed/capacity supporting 
session recording for analysis and freeze capabilities. Initialization download 
capacities for a given reconfiguration turnaround will also be affected. For tra ,ne ’' 
types configured with shared simulation resources, the number and capacity of shared 
services such as audio-video and GSE/stimulation will be proportional to the number 
of concurrent sessions on these trainers. 

The number of concurrently active payloads per trainer may also affect the 
complexity and processing power necessary at each instructor station in order to 
monitor training situations involving several active payloads. 


Cost: 

The major cost factor is the total number of hosts, DMS Kits, and trainer 
components. It should be noted that two module trainers are not equivalent to four 
part-task trainers, and each type will require more of some resources than does the 
other. Further, as more trainers are put in operation simultaneously, more copies of 
the individual flight equivalent payload instruments will be needed. 
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Other cost increases are limited to the PTC/SCS Network scaling to handle the 
proportional increase in instructor station traffic with additional independent training 
sessions. 


Comparison: 

See paragraph 3.2.6 for DMS Kit sizes and details. 


HARDWARE REQUIREMENTS 


FIXED 


INCREMENTAL 


SOFTWARE REQUIREMENTS 


FIXED 


INCREMENTAL 


(a) 

2 US Lab 
Modules, 

0 US Lab 
PTTs, 

3 LoFi 
Sims, 

1 ESA or 1 
JEMPTT 


2 sized Hosts & 2 
sized DMS Kits 
for US Lab 
Modules + 3 WG 
for LoFi + 1 Host 
& 1 ESA & 1 JEM 
DMS Equiv. Kit 
for IP PTTs 


None 


ITVE + DMS S/W 
+ IP DMS Equiv. 
S/W+ Prototyping 
S/W 


LoFi Sim S/W or 
data files for LoFi 
P/L sims 


(b) 

2 US Lab 
Modules, 

3 US Lab 
PTTs, 

1 ESA or 
JEMPTT 


2 sized Hosts & 2 
sized DMS Kits 
for US Lab 
Modules+3 Hosts 
for US Lab PTT + 
1 Host & 1 ESA & 
1 JEM DMS 
Equiv. Kit for IP 
PTTs 


None 


(c) 

2 US Lab 
Modules, 

3 US Lab 
PTTs, 

1 ESA, 1 
JEMPTT 


2 sized Hosts & 2 
sized DMS Kits 
for US Lab 
Modules+3 sized 
Hosts & 3 sized 
DMS Kits for US 
Lab PTTs + 2 
Hosts & 1 ESA & 
1 JEM DMS 
Equiv. Kit for IP 
PTTs 


None 


ITVE + DMS S/W 
+ IP DMS Equiv. 
S/W + DMS 
Simulation S/W 
for non-DMS 
PTTs 


Updates to the 
DMS Simulation 
as DMS evolves 


ITVE + DMS S/W 
+ IP DMS Equiv 
S/W 


None 






TRW-SCS-90-XT2 Baseline Architecture 64 


3.2.11 Per Cent of Flight Equivalent Payload Simulations: 

a) 40% flight equivalent payloads 

b) 10% flight equivalent payloads 

c) 0% flight equivalent payloads 

Training: 

Providing trainers that support flight equivalent payloads will ensure the high 
fidelity payload training required to accomplish the SSF mission 

Realistic aircraft flight simulators are built with no flight equivalent hardware. 
However, these aircraft simulators do not have 4 to 12 of their instruments changing 
every 90 days, as will the PTC trainers. This means the use of flight equivalent 

payload simulations has the potential to be more cost effective. Even the SSTF, which 

is more analogous to the aircraft simulator than the PTC, has adopted DMS Kits to 
supply the proper fidelity of SSF training. 

System: 

Flight equivalent payloads can be supported by utilizing DMS kits with MDMs. 
The quantity of requisite flight equivalent DMS Kit components (hardware & software) 
and SIBs is proportional to the number of supported flight equivalent payloads. 
Conversely, some percent of the time software-only simulation models will be used in 
the same racks, which means that the SCS must encompass the full capability to 
develop and drive each trainer with software models, as well as accommodate flight 
equivalent hardware. 

Cost: 


Supporting flight equivalent payloads is most economical with DMS Kits (see 
3.2.6 "Use of DMS Kits"). 

The trainer host MIPS capacity to execute payload simulation models is a 
multiple of the number of simulated payloads. There are also commensurate sizing 
impacts on the network and simulation executive, among other functions, within a 
trainer. 

More software simulated payloads means more model and associated software 
development as well as more testing. To the extent that useable models are not 
available from the Pis and would have to be developed onsite, there is a proportional 
increase in the number of developer and testing stations and servers. However, the 
IT&V size will remain essentially constant, since the number of payloads to be 
integrated is the same whether they are flight equivalent or software implementations. 
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Comparison: 



0 

in 

QC 

111 

DC 

1 
tr 
< 
X 

UIREMENTS 

SOFTWARE REQUIREMENTS | 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

40% F/E 

60% of WSs & 
hosts in 
development 
facility in option 
(c)** + one sized 
DMS kit per 
concurrently 
operating trainer 
+ 1 MDM for each 
rack supporting 
F/E P/Ls* 

F/E instruments & 
panels for 40% of 
all P/Ls 

Model & panel** 
develop toolsets 

F/E P/L programs 
from Pis + items 
below for (c) per 
60% of P/Ls** 

(b) 

10% F/E 

90% of WSs & 
hosts in 
development 
facility in option 
(c)** + one sized 
DMS kit per 
concurrently 
operating trainer 
+ 1 MDM for each 
rack supporting 
F/E P/Ls* 

As above for (a) 

As above for (a) 

F/E P/L programs 
from Pis + items 
below for (c) per 
90% of P/Ls** 

(c) 

0% F/E 
(100% 
sim) 

34 develop WSs 
of 8 MIPS*** + 
Development 
Host Computers 
(1 for every 15 
developers)** 
+LAN & server for 
each computer 

None (other than 
P/L panel specs 
from Pis) 

As above for (a) 

Develop Sim 
S/W including 
test & integration 
for each P/L** 


* Sized DMS list: 

1 Large DMS Kit per U.S. Lab Module Trainer 

1 Large DMS Kit & 1 ESA & 1 JEM DMS Kit equivalent for the IT&V facility 
1 Small DMS Kit per 4 PTT Racks 
1 Small DMS Kit for development unit test 
1 SIB per Kit 

1 IP DMS Kit equivalent for each set of IP PTTs or each IP Module trainer 

** Impact only if PTC supports P/L model development (see 3.2.15 "P/L Models 
Developed on PTC/SCS") 

*** Workstation quantities are for model development per Section 2.21 of Appendix A. 
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3.2.12 Trainees and Payloads per Quarter: 

a) 90 day crew & 90 day payload increments 

b) 45 day crew & 90 day payload increments 

c) 45 day crew & 45 day payload increments 

Training: 

The options under this issue are a major factor in determining the number of 
concurrent training sessions that have to be sustained in order to complete the 
required number of hours of simulation training on each payload. 

System: 

Enough Module trainers and PTT racks with associated computers must be 
available to support the required training hours. The baseline of 2 US Lab module 
trainers, 9 US Lab PTT racks, 5 JEM PTT racks, and 11 ESA PTT racks will 
accommodate option (a), given enough computer resources to support increased 
concurrent training sessions. Scenarios of, "90d crew & 90d p/I intervals", "45d crew & 
90d p/I intervals", "45d crew & 45d p/I intervals" were examined (See section 1.2.1 for 
results and Appendix C for the analysis details). 

Additional system capacity for storing session scenarios, downloading 
configuration and initializing data, capturing and analyzing session performance, and 
maintaining training records is a multiple of the number of trainers used for training. 

CosL 

The cost comparisons were made with the 10% change out rate shown in the 
comparison table as this is the number currently in use by NASA training. The amount 
of training required doubles when the number of trainees doubles, or the number of 
payloads doubles. Doubling either requires twice as much simulator hands on 
training time. Further detailed analysis by Boeing training personnel has confirmed 
the analysis shown in option (b). See also 3.2.10, "Concurrent Independent Training 
Sessions" and 3.2.13 "Payload Changeout per Increment". 

Comparison: 



HARDWARE REQ 

UIREMENTS 

SOFTWARE REQUIREMENTS \ 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

90d & 
90d 

Baseline number 
of trainers 

1 0% new F/E 
P/Ls per quarter 

Complement of 
F/E sim programs 
per quarter 

10% new F/E or 
model programs 
per quarter 

(b) 

45d & 
90d 

Twice the 
number of 
trainers 

1 0% new F/E 
P/Ls per quarter 

More complex 
Session Mgmt 
Func: 0.5K SLOC 

1 0% new F/E or 
model programs 
per quarter 

(c) 

45d & 
45d 

Four times the 
number of 
trainers 

20% new F/E 
P/Ls per quarter 
+ C&D panels 

More complex 
Session Mgmt 
Func: 10 K SLOC 

20% new F/E or 
model programs 
per quarter 
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3.2.13 Payload Changeout per Increment: 

a) 15% 

b) 12% 

c) 10% 

d) 5% 


Training: 

No effect on training except potential loss of training time while system is being 
reconfigured. 

System: 

The load on the IT&V will increase in proportion to the percent change-out. The 
load on the development function will increase in proportion to the percent change- 
out. 


The change-out rate and number of increments overlapping in the PTC will 
determine the number of co-residing payloads and, thus, the aggregate system 
capacity required for maintaining session scenario and configuration files for a 
particular combination of payloads. 

The reconfiguration time, as a first approximation, would be in proportion to the 
percent change-out. On the other hand, change-out time can be reduced by 
appropriate design of the total system, as discussed below in "Costs:". 

If we hypothesize that three consecutive SSF increments overlap in the PTC at 
any one time (as shown in the training loading analysis, section 1.2.1), the 
accumulated payload changeout is expected to be 15% to 45% of the total PTC 
complement of payload instruments and models. Thus, reconfiguration time is limited 
to that needed for changing over this number of payloads. 

While software downloads should be relatively efficient, C&D panel and flight 
equivalent instrument hookups to MDM and GSE may take some time. Note the 
impact of virtual C&D panels as discussed in Paragraph 3.2.1, "Type of C&D Panel 
Crew Interface". 

New payload simulator development and testing is assumed to be concurrent 
with preceding increment training. 

The completeness (size) of reconfiguration files and the speed of downloading 
required by different alternatives may affect the central storage and communications 
capabilities of the PTC/SCS. 


Cost: 
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The percent change-out affects the cost in a direct manner. The higher change- 
out rates will require more people resulting in higher operational costs. As mentioned 
under "System:", the impact on IT&V and the development facility is in proportion to the 
percent change-out, and so the associated cost. 

Reconfiguration time may be reduced from the adoption of design options such 
as the LAN option for SIB connection in Paragraph 3.2.8, "SIB's Interface to Host 
Computer", or the interchangeable platform option in Paragraph 3.2.24, "Simulator 
Transportability between Module and Part-Task Trainers". The higher costs of rapid 
reconfiguration capabilities are traded off against the loss of use of facility operations 
during periods of reconfiguration and the associated idle manpower of the training 
staff. 


Comparison: 



HARDWARE R 

EQUIREMENTS 

SOFTWARE REQUIREMENTS | 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

15% 

Baseline 
Development *** 
& IT&V Facilities 
upscaled 67% 

Approx 13 new 
SSF P/Ls* 

Basic 

development *** 
and test software 
environment 
required 

PI F/E programs 
or 1 3 X 20K 
SLOC 
programs** 

(b) 

12% 

Baseline 
Development *** 
& IT&V Facilities 
upscaled 33% 

Approx 10 new 
SSF P/Ls* 

Basic 

development *** 
and test software 
environment 
required 

PI F/E programs 
or 1 0 X 20K 
SLOC 
programs** 

(c) 

10% 

Baseline 
Development *** 
& IT&V Facilities 
upscaled 20% 

Approx 9 new 
SSF P/Ls* 

Basic 

development *** 
and test software 
environment 
required 

PI F/E programs 
or 9 X 20K SLOC 
programs** 

(d) 

5% 

Baseline 
Development *** 
& IT&V Facilities 

Approx 4 new 
SSF P/Ls* 

Basic 

development *** 
and test software 
environment 
required 

PI F/E programs 
or 4 X 20K SLOC 
programs** 


* Based on a one week reconfiguration time. If reconfiguration is to be done in 
8 hours, then add 60MB virtual memory. (To buffer downloads of increment 
configuration data sets, simulation models, and session scenarios) + quick 
connect racks + LAN switching. 

** Based on estimate of average payload model size from Spacelab 
experience. See SCS Study Report, Issue T1 in Volume 5, and Section 
2.4, "Payload Representation", of Appendix A. 

*** Impact only if the PTC/SCS supports P/L development. 
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3.2.14 Representation of DIF: 

a) dynamic simulation 

b) table driven simulation 

c) none 

Training: 

Dynamic simulation would provide a high degree of realism of the DIF 
representation. A table driven, or "static" simulation would be of lower fidelity but for 
PTC payload training purposes, would probably be adequate. 


System: 

The DIF simulation under consideration here, whether dynamic or static, is only 
intended to provide the status type information normally provided by the DIF to the 
POIC. Either should be a relatively insignificant increase in system loading including 
some communications increase. 

Cost: 

Estimates of code size for simulating necessary DIF functions are based on 
OMGA estimates and C&T size estimates. The C&T bandwidth being passed on to the 
DIF will determine the additional CPU capacity for processing a dynamic stream. This 
processing is not included in the comparison below but would involve both additional 
hardware, firmware, and software. 


Comparison: 



HARDWARE REQUIREMENTS 

SOFTWARE REQUIREMENTS 1 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

IESI 

2.2 MIPS on MC 
or RS per trainer* 

None 

45K SLOC 
proqram* 

None 

(b) 

static 

0.2 MIPS** on 
PC per trainer 

None 

4.5K SLOC 
program** 

None 

(c) 1 

none 

None 

None 

None 

None 


* Uses combination of OMGA (as sized in Paragraph 3.2.9, "Use of OMGA") 
and C&T (as sized in SCS DMS SRS). See the discussion on software 
sizes from the DMS PDRs in Paragraph 3.2.6, "Use of DMS Kits".) for total of 
45K SLOC, all run at 4 Hz update rate. 

** Estimated at one tenth of dynamic values. 
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3.2.15 Software Payload Models Developed on PTC/SCS: 

a) 50% 

b) 25% 

c) 0% 


Training: 

This issue will have no effect unless trainers are borrowed for use for 
development unit test or as an IT&V facility while development is conducted 
independently for model check outs and debug. 

System; 

The percentage of payload models to be developed will determine the 
development and test capacity requirements required from the system. The number of 
workstations and the host capacities will be directly proportional to the percentage of 
payloads developed on PTC/SCS. In addition, the Development Facility LAN will 
have to be sized to handle increased development related traffic. Payload changeout 
rate affects this (see 3.2.13 " Payload Changeout per Increment). 

Cost: 

The baseline Development Facility and IT&V Facility requirements consist of, by 
the current design, three development hosts, one IT&V host, and 32 workstations. The 
determination of these requirements is discussed further in the "Local Host Design 
section of Volume 3 of the PTC/SCS study. Capacity and costs are approxima tely 
proportional to the number of models to be developed (in the course of a year). Also, 
recurrent communication facility costs for remote access for any of this development 
must be added, changeout rate used was 5%. 
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Comparison: 



HARDWARE REQUIREMENTS | 

SOFTWARE REUl 

JIREMENTS 


FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

50% 

33 develop WSs 
of 8 MIPS* (+PI 
remote interface 
as needed) + 
base IT&V in (c) + 
3 devel. hosts 

None (other than 
P/L specs from 
Pis) 

Model & panel 
develop toolsets 

20K SLOC ** 
models + 2 man 
week virtual 
panel develop, 
per P/L 

(b) 

25% 

50% capacity of 
option (a)(+PI 
remote interface 
as needed) + 2 
devel. hosts 

Same as (a) 

Same as (a) 

20K SLOC 
model + 2 man 
week virtual 
panel develop, 
per P/L 

(c) 

0% 

6 IT&V WSs of 1 1 
MIPS** 

None 

None 

Program test & 
integration per 
P/L 


* Workstations for model development are per Section 2.21 of Appendix A 
with the quantity capable of supporting one payload in 90 days, add one 
WS for developing virtual C&D panels 


** IT&V stations are represented as developer workstations with additional 
MIPS per Section 2.24, "Integrate and Test Simulations", of Appendix A 

*** This limitation is based on the assumptions on number of programmers 
developing software (33) and the productivity rate given in Paragraph 3.2.3, 
"Fidelity of Payload Models" 
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3.2.16 PTC/SCS Remote Developer Capability: 

a) use for all simulated payloads 

b) use for 50% of simulated payloads 

c) none 

Training: 

No effect. 


System: 

Providing a remote developer capability is implemented by the provision of high 
speed dial-up ports in the development facility. The capability also requires loca^ 
support for hardware reconfiguration. Additional software support for security and 
configuration management will likely be necessary. 

Cost: 

The basic cost is the addition of one communications port/modem (assumed 
9600 baud performance) to the SCS System Management Host for each external 
payload model. Of course, a continuing operational cost will be the phone line 
charges necessary to support remote developers. Also, overhead costs of bub 
communications and executive functions will increase the host capacity requirement 
by about 0.2 MIPS per external model. 

A secondary cost results from the security problems jnherent with remote phone 
access. This concern must be met with adequate security safeguards - at greater 
system cost - to insure that no unauthorized system use is possible due to remote 

access. 

In compensation, as the amount of remote access is increased, 
accommodations for local access can be reduced. 
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Comparison: 



HARDWARE REQUIREMENTS 

SOFTWARE REQUIREMENTS 

FIXED 

INCREMENTAL 

FIXED 

INCREMtN 1 AL 

(a) 

all 

36 dial-up ports* 
and modems + 
7.2 MIPS (+ SCS 
develop 
resources) 

None 

None (other than 
Security & 
Management) 

None 

(b) 

50% 

18 dial-up ports* 
and modems + 
7.2 MIPS (+ SCS 
develop 
resources) 

None 

None (other than 
Security & 
Management) 

None 

wswm 

None 

None 

None 

None 


* Based on SLOC productivity estimates (150 SLOC per man month), 
estimated size of payload models (20K SLOC) and number of new 
payloads per 90 day period (6-9). To size a reasonable worst case, 90 /o 
S/W models are assumed here. The quantities would be halved if approx. 
50% F/E payloads were used (per discussion in Paragraph 3.2.3, Fidelity 

of Payload Models".) 
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3.2.17 Consolidated Increment Training: 

a) provide dedicated trainer 

b) provide for linkage of US Lab module trainers with IP PTTs 

c) none 

Consolidated Increment Training is, in the PTC context, payload training for 
payloads (a realistic shipset of all that could be running simultaneously given power 
and other resource constrains) in all three Labs (US, ESA, and JEM). 

Training; 

Providing this training utilizing a dedicated trainer (a) would provide 
Consolidated Increment training and a readily available Operations Evaluation 
capability to simulate and solve inflight payload problems. However, the amount of 
this type of training required is small (less than 32 hours per increment based on 
Spacelab experience.) 

Option (b) would provide limited Consolidated Increment training since the IP 
PTTs hold only US sponsored payloads, and the IP PTTs will not be positionally 

correct. 

System; 

Option (a) would require a separate trainer consisting of three modules (US, 
ESA, & JEM) and associated DMS Kit and Data System Kits for the IP modules and a 
host computer. 

Option (b) can be implemented by utilizing the existing US Lab module trainers 
with a real time LAN between the host computers and some added software to 
coordinate. 

An alternate way of implementing Option (b) would be to have a second 
connection from each IP PTT to a larger host computer that could dnve aH three 
trainers. This would eliminate the required real-time LAN. Some additional 
coordination software would still be required. 

There would be some additional software in the Session Management Function 
for Option (b) to provide selective session control over multiple trainers. 

Cost: 

The cost of Option (a) is essentially the cost of three module trainers, three DMS 
Kits or Data System Kits (including a SIB and two SIB equivalents), a large host 
computer, plus the cost of adding two gateways to interconnect the trainers. 

Option (b) can be implemented simply by providing two sets of 
gateways/bridges: one set interconnecting the Trainer LANs; and one set 
interconnecting the Trainer Hosts, and some additional control software. 
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Comparison: 



HARDWARE REQUIREMENTS H 

SOFTWARE REQUIREMENTS | 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

dedi- 

cated 

trainer 

3 module trainers 
+ 3 DMS strings 
+ 2 bridges + SM 
of 47.5 MIPS* + 1 
SIB + 2 SIB 
equivalents + 1 
A-V unit + 4 WS 
of 16 MIPS** 

Replicates of F/E 
P/Ls for 
simultaneous 
module & 
consolidated 
training 

Approx 2K SLOC 
for reconfig. 
function in the 
Session 
Management 
Function 

None 

(b) 

limited 

4 bridges + a 
real-time LAN + 1 
A-V unit 

None 

Approx 2K SLOC 
for reconfig. 
function in the 
Session 
Management 
Function + COTS 
S/W for LAN & 
bridge 

communications 

None 

(c) 

none 

None 

None 

None 

None 


* Consolidated trainer host estimate for SCS Local Host design per Refined 
Conceptual Design Report, SCS Study Report Vol. 3, Section. 3. 3.3. 


** Workstation sizing for Instructor Station per Section 2.1 1 , "Instructor Control 
and Monitoring", of Appendix A. 
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3.2.18 POIC Interface: 

a) full bandwidth (100 to 300 Mbps) 

b) limited bandwidth (10 Mbps) 


Training: 

Considerations here concern the realism of the POIC interface. Use of the full 
bandwidth (100 to 300 Mbps) is necessary to support a High Rate Link, which in turn is 
necessary to support graphics data transfer. However, from a training point of view, 
the system only has to appear to be transferring this data. Therefore the full bandwidth 
is not required for crew or POIC training purposes, but may be required by Pis for high 
rate data. Closely related is the function of dynamic data generation vs. static data 
generation. Dynamic generation could provide a much more realistic simulation to the 
trainee than static. However the effect on quality of training is marginal. 

System: 

The interface for command/status and audio traffic, while substantial, is 
straightforward. The high rate link data generation, however, must be supported 
dynamically within the PTC in order for this data to be scientifically meaningful. If the 
full bandwidth option (100 to 300 Mbps) is chosen, data would pass through the C&T 
processor/controller. At the present time, bandwidth beyond 100 Mbps must be 
supported by implementing multiple channels. However, by AC it is reasonable to 
assume that single fiber links of 300 Mbps will be available. 

High rate science data goes directly from the payload to the user via the PTC 
High Rate Link (HRL) system. The rate at which dynamic or static data has to be 
generated will determine the complexity of each implementation option. 

It makes sense to assume as a reasonable worst case that the full bandwidth 
channel requirement is limited to one trainer session concurrently, and thus the facility 
would be shared among trainers. 

The effect on complexity and cost is an interaction between the bandwidth 
alternatives and the source alternatives (dynamic, table driven, etc.). 

The POIC interface is implemented using the SCS System Manager Host to 
control the routing and synchronization of the data interchange. In implementing this 
link, the 100 to 300 Mbps option involves an order of magnitude more complexity and 
cost than the 1 0 Mbps option. 

To generate the data, pre-programmed streams might be supported centrally for 
all trainers. Whether centralized or distributed, large and fast mass storage will be 
required, limited by the assumption that only one such stream is passed on to the 
POIC at one time. 



TRW-SCS-90-XT2 Baseline Architecture 77 


Cost: 

The hardware requirements consist of a network adapter and router that can be 
controlled by the SCS System Manager Host or a separate host and provide the 
prescribed throughput, plus the network interface unit and the physical network media 
connecting to the POIC line. Currently, the cost differential for a FDDI implementation 
of the full bandwidth option versus an Ethernet implementation of the limited 
bandwidth option (10 Mbps) is at least 10:1. This differential may decline to around 
5:1 in time for an SSF AC version of the PTC/SCS. 

The cost to generate full bandwidth dynamic data streams consists of: 1 ) the 
payload source generation, and 2) the subsequent C&T processing. The former, 
although interactive, could reflect bandwidth stemming primarily from large blocks of 
cohesive data (e.g., buffered image frames) that would not react on the fly to 
concurrent simulation events. Temporal dynamics would only take effect at the 
juncture between such blocks. Consequently, the cost of source generation is 
considered not to exceed a 2 MIPS payload model allocation. 


Comparison: 



HARDWARE REQUIREMENTS | 

SOFTWARE REQUIREMENTS ] 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

full 

band- 

width 

2 FDDI NIU/BIAs 
+ resize the 
Session 
Management 
host by 1 MIPS* 
(+ C&T Processor 
of 10 MIPS**) + 
an additional 2 
MIPS per P/L 
model w/HRL + 
C&T processor + 
A-V processor + 
GSE + P/L stim. 

None 

8K SLOC for 
interface function 
in the Session 
Management 
Function* + (Hi-fi 
environ, model)** 

When not F/E, 
may need P/L 
models with 
dynamic HRL 
capability 

(b) 

limited 

band- 

width 

1 Ethernet 
NIU/BIAs + resize 
the Session 
Management 
host by 1 MIPS* 

None 

If dynamic, add 
(Hi-fi environ, 
model)** 

None 


* Estimate for process and control of the POIC interface is per Section 2.8, 
"POIC-DMS Interface", of Appendix A. 


** Dedicated C&T processor to enable POIC link is estimated in Section 2.9, " 
PTC-POIC Link", and Section 2.3.2, "Processing Requirement" of Appendix 
A. 
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3.2.19 Training Sessions with UOF/ROC/DOCs: 

a) interactive in real time (via the POIC) 

b) interactive in real time (simulate the POIC) 

c) none 


Training; 

Without this function, realistic training between the PTC and the 
UOF/ROC/DOCS will have to be accomplished by some other means. 

System: 

For this linkage to be meaningful, a real time full duplex interchange of dynamic 
data must be achieved. 

If the actual POIC is not tied into this loop (per Paragraph 3.2.18, "POIC 
Interface"), then the POIC function will have to be simulated via PTC operations 
personnel, PTC consoles, and software. 

Cost: 

Costs include a C&T Processor/Controller and associated hardware/software. 
See also paragraph 3.2.18, "POIC Interface". 


Comparison; 



HARDWARE REQUIREMENTS | 

SOFTWARE REQUIREMENTS 1 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

dynam- 

ic 

interac- 
tion via 
POIC 

C&T Proc/Cont + 
C&T DMS kit with 
C&T SDP 

None 

C&T Proc/Cont 
S/W + C&T DMS 
kitS/W 

Implement HRL 

dynamic 

generation 

(b) 

dynam- 

ic 

interac- 

tion, 

POIC 

simula- 

ted 

C&T Proc/Cont + 
C&T DMS kit with 
C&T SDP plus 
POIC 

Console/Work 

Station 

None 

C&T Proc/Cont 
S/W + C&T DMS 
kit S/W plus POIC 
Sim. S/W 

Implement HRL 

dynamic 

generation 

(c) 

none 

None 

None 

None 

None 
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3.2.20 Use of MODB/RODB: 

a) all simulation models 

b) limited to Core and DMS models 

c) not used 


Training; 

Use of real MODB/RODB software and constructs will give trainees more 
confidence in the PTC provided payload training. 


System: 


Adoption of the SSF software protocol and dictionary library impacts all 
simulation model and data interchange constructions. While this formalism may force 
the models to have broader scopes and format overheads, the potential for improved 
code reusability and ease of modification more than outweigh the disadvantages. 


While the SSF Program requires that Pis use the MODB/RODB in their payload 
and payload model software, Option (c) is included for comparison. 

The most important aspect of the use of MODB/RODB is that it would provide a 
higher DMS compatibility and SSTF compatibility in the developed software. 


Cost: 

Note that software is already available from WP02 and prototype RODB 
software has been run as part of the SCS study. Since this has been done, 
MODB/RODB should be used in any DMS Kit implementation of SCS. 


Comparison: 



HARDWARE REQUIREMENTS | 

SOFTWARE REQUIREMENTS 1 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

all 

models 

Greater on-line 
storage required 

None 

Development 
toolset for Pis & 
PTC staff 
supports 
MODB/RODB 

Sourced P/L 
models conform 
to MODB/RODB 

(b) 

Core & 
DMS 

Slightly greater 
on-line storage 
required 

None 

Development 
toolset for PTC 
staff supports 
MODB/RODB 

None 

(c) 

none 

None 

None 

None 

None 
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3.2.21 Use of Ada: 

a) all software 

b) simulation models only 

c) none 

Training; 

No effect. 


System: 

Real time Ada works and is being used in numerous DOD systems. Case tools 
for the development of real time Ada are available. The efficiency of their code 
products will be adequate for PTC applications. The availability and suitability of Ada 
for some of the SCS systems software is not likely because of industry trends (toward 
C) and the need to implement low level functions (some in assembly language). 

It is not known whether it will prove practical to impose Ada on payload models 
developed by the Pis. Payload models in different languages would be hard to link 

together. 

Cost: 

If Ada is mandated for all SCS, suitable COTS software (in other languages) 
may be eliminated, requiring more expensive custom software. When custom software 
is required the initial low programmer productivity may increase development costs. 
Ultimately, the improved code reusability gained with Ada should reduce long term 
system Growth costs. Code compatibility with SSF will be important to facilitate 
transportability. Payload models in different languages would increase operations 

costs (CM). 


Comparison: 



HARDWARE REQUIREMENTS 1 

SOFTWARE REQUIREMENTS ] 

FIXED 

INCREMENTAL 

FIXED 

INCREMfcIM 1 AL 

(a) 

all S/W 

An Ada 

development 

facility 

None 

All custom 
system & trainer 
programs 

P/L models are PI 
or PTC provided 
in Ada @ TBD 
ratio 


An Ada 

development 

facility 

None 

All SSF and 
ground 
simulation 
models 

P/L models from 
sources in 
different 
languages 

(c) 

none 

Non-Ada 

development 

facility 

None 

If non-DMS, 
potential 30% 
COTS O/S, Sim 
Exec, etc. 

P/L models from 
sources in 
different 
languages 
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3.2.22 Use of SSE/ITVE Tools: 

a) all software 

b) simulation models only 

c) none 


Training: 

No effect on training. 

System: 

The use of SSE /ITVE tools in the PTC development facility (Options a or b), and 
compatibility with SSFP software standards affords technical and economic 
advantages. If other NASA centers follow these SSF standards, the PTC software 
should transport fairly easily to other training facilities like the SSTF. The SSE/ITVE 
package, however, may not represent the best tools for each specific job, in our case 
developing simulation models and code. ITVE will provide data base software 
(MODB.RODB), interfaces to DMS Kits, and simulation control software that are 
essential. 

No use of SSE/ITVE (Option c) means a different suite of tools must be 
assembled and built which may or may not be compatible with other SSF centers. 

This issue will have no negative effect on the system unless the suite of tools 
restricts the real time efficiency of the code products, or the extent of the code's control 
of I/O, interrupts, and memory. 

Cost: 

The incorporation of these development and testing tools in the PTC 
development facility will be inexpensive compared to purchasing and building a 
comparable suite of tools. Their implementation may not be the most efficient in a 
specific situation for producing code. However, replacing SSE/ITVE tools with others 
will cost significantly more. Also, replacing the ITVE data base software 
(MODB.RODB), interfaces to DMS Kits, and simulation control software would be very 
expensive. 

Since under the present plan, WP02 does not plan to respond to any specific 
requirements from the PTC, but will allow the PTC to use the ITVE products “as is" to 
make use of the ITVE products, the PTC/SCS design must be engineered to 
accommodate them. Note that ITVE simulation executive is expected to provide only 
simulation modes as discussed in Paragraph 3.2.33, “Simulator Modes". 
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(a) 

all S/W 


(b) 

sim 

models 


(c) 

none 


HARDWARE REQUIREMENTS 


FIXED INCREMENTAL 


restricted vendor None 
platforms 


restricted vendor None 
platforms 


Marginal 

additional 

development 

systems or 

increased 

development 

time 


SOFTWARE REQUIREMENTS 



FIXED 


Restricted 
languages & 
development 
methods likely for 
all custom 
software 


as above for 
simulation model 
development 
only 


Increased cost 
(as much as 
100%) on tools & 
updates to tools + 
development of 
ITVE DB, l/F, & 
sim control S/W 


INCREMENTAL 


None 


None 
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3.2.23 Payload Simulator Transportability to SSTF: 

a) via provision of turnkey system - SSTF to use SCS design & 
host 

b) via conversion 

c) via adoption of SSTF design 


The options defined above as well as the secondary issue of whether to use 
SSTF hosts are discussed below. 

Training; 

Fidelity of payload proficiency training at the SSTF will have a big effect on crew 
training. 

System; 

A turnkey system would provide the payload, DMS, and host portions of the 
simulators that would interface directly to the SSTFs Core, environment, and session 
control systems. Option (a) assumes the platform to be the SCS host with DMS, 
payload software, and I/O subsystems for flight equivalent instruments and C&D 
panels. The turnkey system would include appropriate extensions to interface with the 
SSTF Core systems and session management control. Minimum cost, overall, can be 
expected to come with the PTC/SCS host because its selection criteria are founded 
strictly on efficient payload simulation. 

The conversion approach of Option (b) would convert the payload and DMS 
software and computer/hardware interfaces to accommodate the SSTF, rather than 
implement a design that provides a plug compatible standalone payload simulator 
system or a design that provides a dependent SSTF subsystem. Option (b) assumes 
that the SSTF uses its own payload host and DMS components. The PTC/SCS must 
then be designed from the outset to include the appropriate hooks in PTC/SCS 
payload software and scars in I/O components. To tie the provided system directly into 
the SSTF and its executive control would then only require conversion. 

The conversion option is intended to provide the same systems to the SSTF, but 
without constraining the initial PTC/SCS design with built-in SSTF compatibility. 
Instead, the SCS payload software and subsystems are converted after the fact to run 
in the SSTF environment. It is assumed that the most practical implementation of this 
alternative would involve the development of conversion utilities to automate the PTC- 
to-SSTF software translation. Similarly, intermediate conversion equipment would be 
provided to achieve the proper I/O compatibility. 

Option (c) means that the PTC/SCS replicates the SSTF design for payload 
simulation and enforces this as the PTC design. The design, which uses four sets of 
DMS Kits with full strings of SDPs, SIBs, and the SSTF hosts, is based on flight 
equivalent software. 
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In contrast to other alternatives, Option (c) determines the trainer interfaces that 
all PTC/SCS systems must support. Option (b), on the other hand, imposes the 
additional systems support and user labor for the SSTF conversion process. 

Cost: 

The turnkey approach in Option (a) presents the least impact on the PTC/SCS 
design and a negligible increment in the PTC/SCS cost. The cost to the SSTF for the 
turnkey system in this option is essentially the sum of the costs of the individual lab 
trainers required by SSTF less the host CPU capacities reserved for Core and 
environment model execution. The host downsizing amounts to a 35 percent 
reduction in MIPS (per Section 3.3.3 of Volume 3, “SCS Study Report”). 

Option (b) relies on the development of efficient gateways and software utilities 
to convert between SSTF and SCS protocols and logical structures. A gateway would 
be required for each trainer between its Payload Trainer LAN and the SSTF Real Time 
Simulation Network, as well as a gateway between the central host (SCS) LAN and 
the SSTF General Purpose Network. Logical conversion of object structure and 
relations could occur at two levels: one operating at run time as a preprocessor; and 
the other as a translation utility used to convert PTC/SCS software modules into SSTF 
software modules during redevelopment. Additional protocol conversion is assumed 
to occur in the gateways. 

Conforming to the SSTF design in Option (c) means adopting the full DMS 
implementation and support of flight equivalent software, restricting models to the 
MODB/RODB dictionary, and providing additional hooks and scars where necessary to 
interface with SSF simulation and system executive control. This presumably would 
require compatibility with Ada in a Unix runtime environment. 

The bottom line is the difference in acquisition and maintenance costs for the 
SSTF hosts versus the chosen PTC/SCS hosts. While the PTC/SCS hosts can be 
sized exactly to meet payload simulation software and communications loads, the size 
of the SSTF hosts would be predetermined and could necessitate using multiple units 
or sacrificing simulation performance. For the expected high unit price of the SSTF 
host, much more cost efficient distributed processing host solutions could be 
implemented in the PTC/SCS. 
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Comparison: 



HARDWARE REQ 

UIREMENTS 

SOFTWARE REQUIREMENTS ! 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

provide 

turnkey 

system 

Any vendor* host 
and F/E or non- 
DMS 

components per 
trainer + Host l/Fs 
for SSTF RT Sim 
& GP Networks 

P/L instruments 
when F/E or C&D 
panels are used 

F/E and/or 
simulation S/W + 
PTC/SCS system 
programs + sim 
programs 

F/E P/L S/W, 
and/or P/L 
models and 
virtual C&D panel 
development 

(b) 

convert 

Any vendor* host 
and F/E 
components or 
non-DMS 
components 
including 
gateways per 
trainer 

P/L instruments 
when F/E or C&D 
panels are used 

As above plus 
approx. 10K 
SLOC 

conversion S/W 

Same as above 

(c) 

adopt 

SSTF 

design 

SSTF host with 
proprietary I/O (+ 
DMS Kits + SIBs) 
per trainer 

F/E P/L 
instruments 

SSTF F/E and 
simulation S/W 

F/E P/L S/W, P/L 
models and 
simulation S/W 


* 


Any vendor means that the choice of trainer host is not required to be same 
as used at SSTF. 
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3.2.24 Simulator Transportability between Module and Part-Task 
Trainers: 

a) interchangeable DMS hardware-software platforms 

b) compatible hooks & scars, via conversion 

c) interchangeable non-DMS 

d) none 


Training: 

Greater interchangeability would mean easier configuration and training 
scheduling. 

System: 

In Option (a), compatible host systems including hardware, software and DMS 
Kits are used. While the host systems share the same operating system and 
input/output drivers (in order to support the same simulation software), trainer hosts 
could vary in their level of CPU capacity, coprocessor support, and input/output 
capacity. Both types of trainer platforms would run of the same simulation software 

code. 


The approach of Option (b) would allow the Module and Part-Task Trainers to 
have independent designs and different hosts, based on the requirement that _the 
PTC/SCS be designed from the outset to include the appropnate hooks in PTC/bob 
payload software and scars in I/O components to allow transportability between the 
modules and part-task trainers. Then conversion utilities would be developed to 
automate the part-task to module software translation. Similarly, intermediate 
conversion would be provided to achieve the proper I/O compatibility. The US Lab 
module trainers are assumed to have the DMS Kits. Thus, no flight equivalent 
payloads or flight software could be accommodated in the PTTs. 

Option (c) is the non-DMS Kit or DMS equivalent option. All trainers would 
have compatible hosts, including software and hardware. 

Option (d) would allow optimum matching of simulation tasks to the hardware 
and software. 

Cost: 

Option (a) means that if any lab trainers require a full flight equivalent DMS 
representation, for example, then all trainers would have a flight ©qwvatent 
implementation and the associated capabilities and costs. However a COTS interface 
to C&D panels can be supported in the same PTC payload rack that contains DMS 

interface hardware. 

Option (b) would permit flight equivalent DMS and software simulation to co- 
reside in the PTC. The difficult part is designing the proper hooks and scars to make 
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conversion work. Software utilities would have to be developed to convert between 
module and part-task protocols and logical structures used in the simulation software. 
Translation utilities would be used to convert PTT trainer simulation software into 
module trainer software during initial development. 

Option (c) is all compatible non-DMS, so models could move easily from PTT to 
module trainer. 

Option (d) would result in the minimum development cost since the module and 
part-task systems would have hardware and software of optimum size and functions 
for the respective simulation tasks. Two different models would have to be developed 
for module and PTT training however which would significantly increase operations 
and payload development costs. 



HARDWARE REQUIREMENTS 
FIXED I INCREMENTAL ' 

(a) Same or scalable Accommodates 
com- host for each F/E instruments & 
mon trainer type (+ all panel and C&D 
DMS DMS Kits if F/E panels 

plat- required) 

forms 

(b) Common host l/F Accommodates 

hooks & & common non- F/E instruments & 
scars, & DMS I/O + panel and C&D 

convert special custom panels 

I/O H/W for FE 
P/Ls + Dev. Sys. 

MIPS for S/W 
conversion 


(c) Same or scalable No F/E 

com- host for each instruments & 

mon trainer type panels 



SOFTWARE REQUIREMENTS 


FIXED 

INCREMENTAL 

DMS S/W 

Use same P/L 

models 

regardless 

DMS S/W + 
Simulation S/W, 
where differing, 
must have hooks 
+ S/W conversion 
utilities & I/O 
conversion 
programs 
SLOC= 15K + 
50K SLOC LoFi 
DMS S/W sim 

P/L model S/W, 
where differing, 
must have hooks 
+ conversion 
labor per P/L 

COTS S/W + 
ITVE & SSE 
replacement S/W 

P/L models must 
conform to PTC 
l/F 

DMS S/W + 50 K 
SLOC DMS Kit 
S/W sim 

Use different or 
converted P/L 
models (2 
required for each 
P/L) 
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3.2.25 Attached Payload Representation: 

a) use dedicated trainer 

b) attach to module/ use part-task trainers 


Training: 

Use of a dedicated trainer would allow more realism, plus greater availability of 
training time. 

System: 

Both options could increase the total number of trainers depending on training 
load schedules, but sharing of part-task trainers offers the opportunity to minimize any 
increase. Or, the attached payload trainer could be linked to a module trainer and 
treated as an additional payload, or set of payloads, within the module trainer. 

Dedicated trainers will entail unique design and implementation work at 
additional cost. This option also increases the overall complexity of the PTC/SCS and 
the payload simulation system for the SSTF. 

Additional (concurrent) and unique trainers place a greater load on system 
facilities and capacities by requiring more LAN and CPU capacity. 

Cost: 

Design and implementation costs will be higher for the dedicated trainer but the 
effort could borrow heavily from the part-task and module trainers, resulting perhaps in 
only a 10 to 15 percent increase over comparable module/part-task unit trainer costs. 


Comparison: 



i HARDWARE REQUIREMENTS ] 

SOFTWARE REQUIREMENTS ] 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

dedi- 

cated 

trainer 

Additional host + 
more LAN 
capacity + node 
trainer 

F/E P/L with 
instruments from 
Pis 

Set of standard 
module trainer 
S/W 

F/E or model P/L 
S/W 

(b) 

module/ 

use 

part- 

task 

Any unique MDM 
features for 
attached P/Ls + 
additional 
module trainer 
host capacity 

Same 

2K SLOC 

reconfig. 

program* 

Same 


* Estimate for trainer reconfiguration function for options in Paragraph 3.2.17, 
"Consolidated Increment Training" 
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3.2.26 Payload Video Representation: 

a) dynamic 

b) canned playback 


Training: 

Dynamically generated video and/or rendered computer generated imagery 
would greatly improve the realism of the scenes, which in turn, would improve the 
training value of the simulations. 

System; 

The options are related to Paragraph 3.2.18, "POIC Interface" to the extent that 
the high rate science link can include video data. Video data is also transmitted to the 
POIC via a separate link. Video is presented on MPACs to the crew (trainees) and to 
instructors on their consoles. 

Dynamic generation implies that a visual scene is being generated (with a 
graphics adapter) in response to real time payload, environment, and crew 
interactions. The scenes may also be selected and manipulated in real time from 
stored video data. Additionally, live (NTSC) video may be mixed with either generated 
source in real time. Coprocessor support of the video generation and mixing is 
assumed. 

Canned playback may include any or all of the above mentioned video sources, 
but none of these sources would respond dynamically to simulated SSF, crew, or 
ground events. Instead, a pre-programmed (or pre-recorded) scene or animation 
would be presented. 

The fidelity options distinguish between mixed or single source video modes, 
combined with 3D rendering or the more cartoonish “2 1/2 D” solid color displays and 
animations. The video adapter, display screen, and geometry CPU are all simpler and 
less expensive with 2D CGI (or NTSC) for a given raster resolution. Rendered 
computer generated imagery (CGI) plus NTSC becomes necessary when depth 
perception or apparent detail are relevant to training objectives. Mixing capabilities to 
overlay live or recorded NTSC video with computer graphics may provide a cost 
effective solution to achieving large volume or complex scene generation. 

Because the (concurrent) use of payload video is expected to be low, the video 
generation subsystem may be centralized so it can be shared by all trainers. If usage 
is high, a related impact could be the addition of centralized optical disk or magnetic 
tape storage of payload video to support either type of video generation. 


Cost: 
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Assuming that the canned video is provided by video tape, the additional cost of 
dynamic generation is that of a fast 24 bit graphics adapter with double buffered 
resolution of at least 800 X 600 lines, plus the cost of a real time video mixer to merge 
graphics and NTSC video. The ancillary host and LAN support for payload video 
generation is approximately the same for either option. Cost of the Audio/Video 
system can be kept down by the use of COTS software. 

The use of 2D CGI (or NTSC) option does not include a video mixer to combine 
CGI with NTSC, or a specialized graphics adapter, embedded CPU, and processing 
software to support rendering. 


Comparison: 



HARDWARE REQUIREMENTS 

SOFTWARE REQUIREMENTS \ 

FIXED ] 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

dynamic 

dynamic 
generation 
requires A-V 
system unit* per 
several trainers 

F/EP/L 
instruments & 
panels including 
video peripherals 

6K SLOC A-V 
system programs 
+ development 
toolset 
supporting 
dynamic video 
generation 

P/L models 
capable of 
generating video 

(b) 

canned 

play- 

back 

canned playback 
requires Video 
source & storage 
unit** 

none 

1.5 K SLOC 
simple A-V 
function included 
in trainer's Sim 
Exec 

P/L models 
capable of 
triggering video 


* The A-V System is taken to consist of a frame buffer, 10 MIPS graphics 
engine, mixer, general CPU of .5 MIPS, host l/F, and broadband network, 
plus peripherals including VCR/video-disk and CCTV camera 

** Minimally, this capability can be satisfied with a VCR and/or CCTV camera 
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3.2.28 Payload Stimulation: 

a) full stimulation 

b) limited stimulation (for individual payloads) 

c) none 

Payload stimulation is defined as realistic physical or electronic input that 
represents the SSF and external environment to the hardware payload simulation, 
including flight equivalent payloads. 

Training; 

For realistic simulation, stimulation must be provided. The stimulation 
signals/forces that will be necessary to evoke realistic performance (sufficient to satisfy 
training objectives) from hardware payload simulations will vary greatly from payload 
to payload. 

Full stimulation would add little in training value over the judiciously selected 
selected stimulation offered in Option (b). Option (b) would selectively support 
hardware payload simulations with the minimum stimulation to evoke response that 
cannot be simulated. Payload stimulation is likely to be fashioned uniquely for each 
hardware payload simulation. 

For Option (b), stimulation can be done by software in the host via the SIB 
connection to the MDM, SDDU, GSE port, or MDM ICE. 


System; 

Full stimulation would require a complex simulation of the SSF and external 
environment with associated hardware and software to drive the training simulator 
hosts. 


Limited stimulation would only provide stimulation of high fidelity where 
needed. Based on training requirements, stimulation for many hardware payload 
simulations may be very simple or not provided. In some cases a simple manual input 
may be sufficient. 

Cost: 

A payload stimulator will minimally consist of several channels of input/output 
with analog-digital conversion and perhaps simple energy sources such as light and 
heat to stimulate hardware payload simulation sensors. Full stimulation will include 
more sophisticated energy sources such as magnetic fields as well as mechanical 
effectors under real time control. In some cases, direct connection to hardware 
payload simulation internals may be implemented to inject signals emulating the 
effects of external stimulation. 
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Comparison: 



HARDWARE REQUIREMENTS 

SOFTWARE REQUIREMENTS | 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

full 

stimu- 

lation 

Signal and 
energy supply 
fixtures* + .1 
MIPS per P/L on 
MC/PA for 
control** 

None unless 
unique l/F for 
H/WP/L 
simulations 

4K SLOC control 
program** 

H/WP/L 

simulations 

(b) 

limited 

stimu- 

lation 

Subset of Option 
(a) depending on 
individual 
training 
requirements 

None 

2K SLOC control 
program** 

Same 

(c) 

none 

none 

none 

none 

none 


* Payload stimulation includes electronic/optical signal (analog & digital), 
radiant energy, magnetic, mechanical input, etc. 


** Combined GSE and stimulation control function is estimated in Section 
2.10, "GSE Control", of Appendix A. 
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3.2.29 Instructors per Trainer : 

a) one 

b) more than one 


Training: 

With the proper resources and system design, an increased number of 
instructors would provide a proportionate improvement in training over what one could 
provide. 

System: 

A simple design would be to connect an instructor workstation to the controlled 
trainer. This is a poor design from a reliability standpoint, since one failure could bring 
the whole trainer down. A better design would be to put the workstations on the LAN 
with associated software to allow any instructor workstation to connect to any trainer. 
This would eliminate this "single point of failure" problem. A further extension would 
be to increase the number of instructor workstations beyond the number of 
concurrently active trainers. This would allow for more than one instructor to control 
one training session. The only additional design consideration would be to deal with 
conflicting commands. A small system load will result from the requirement to provide 
controls to preclude conflict in addressing the same payload by different instructors. 
This load is included in the software estimates in the comparison table below. 

The option of more than one instructor is assumed to apply only to module 
trainers (or consolidated trainers). 

This cost driver also affects the bandwidth of the common audio/video link 
(because the audio/video feed, which is separate from the LAN, is individually 
selected). 

Cost: 

Because multiple instructors may be concurrently monitoring and controlling 
different payloads or aspects of the training scenario, the number of instructors will, in 
the worst case, cause the real time traffic load on the PTC/SCS Network to increase in 
proportion to the number of instructors. If instructors are assumed to have full 
capability for training session management (i.e. not partitioning of capabilities across 
instructors), the "more than one instructor" option will scale up the network load one 10 
Mbps notch for every ten concurrent training sessions. 
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Comparison; 



HARDWARE REQUIREMENTS | 

SOFTWARE REQUIREMENTS ] 

FIXED 

INCREMENTAL 

FIXED [ 

INCREMENTAL 

(a) 

one 

8-10 WSsof 16 
MIPS* W/A-V + 
SCS LAN + 1.1 
MIPS** on MC*** 

None 

10K SLOC 
control & 
monitoring 
program (+ 
support from the 
Session 
Management 
Function & Sim 
Execs) 

None 

(b) 

greater 

than 

one 

1 WS of 16 
MIPS* w/ A-V + .1 
MIPS on MC*** 
+1 Mbps 

increase on SCS 
LAN for each 
addt’n instructor 

None 

Program as 
above plus 2K 
SLOC for 
concurrency mgt. 

None 


* Workstation estimate for Instructor Station is per Section 2.11, "Instructor 
Control and Monitoring", of Appendix A. 

** instructor interaction with the Session Management Function is estimated at 
slightly more than 0.1 MIPS per payload. 

*** Sized to handle the given instructor complement in 6 concurrent trainer 
sessions. 
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3.2.30 U.S. Payloads In International Partners’ Modules: 

a) use IP Data System Kits 

b) simulate their system 

c) treat as U.S. module payloads 


Training: 

Use of International Partner (IP) Data System Kits would provide high fidelity 
training with high crew confidence in the training. 

System: 

Option (a) is thought to be the most likely situation. This means that an 
International Partner (IP) Data System Kit must be supplied for each IP Part-Task 
Trainer or module trainer. The hardware and software required for Option (b) depends 
on the characteristics of the IPs' payload data systems for the SSF. Sufficient 
information to permit simulation is just beginning to be available. Option (c) might be 
viable if International standard P/L racks can be agreed upon. However , other issues 
arise, including the functionality of the IP Workstations. 

Cost: 

For Option (a), it is assumed that IP Data System Kits will connect to ITVE 
architecture A or B, and that the kits will be available from the IPs -- also, 
documentation, users manuals, spare parts, maintenance, etc. These Data System 
Kits must work with ITVE simulation control software. 

For Option (b), hardware and software will be needed. Also designs of IP Data 
System Kits will be needed. Note that there will likely be schedule problems with this 
approach. 

For Option (c), we will need more DMS kits and associated peripherals. Issues 
to be resolved include interfacing to IP FMPACs or ECWS. 
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Comparison; 



1 HARDWARE REQUIREMtN 1 S 

SOFTWARE REQUIREMENTS \ 

FIXED ~| 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 1 

Int’l Kits 

IP DMS kit w/ 
MDM + custom 
SIB w/ host l/F + 
FDDI bridge per 
trainer 

H/WP/L 
instruments or 
panels 

Int’l Partner DMS 
S/W + custom 
sim l/F programs 

F/E P/L S/W or 
P/L model 
compatible with 
Int’l Partner DMS 
environment 

(b) 

simulate 

I/O Processor + 
host l/F + FDDI 
bridge per trainer 

Same 

40K SLOC 
simulation of 
each IP’s DMS** 

F/E P/L S/W or 
P/L model 

(c) 

U.S. Kit 

1 DMS kit for 
each IP trainer* 

Same 

Same as for 
other DMS kits* 

F/E P/L S/W or 
P/L model 


* Complies with the trainer implementation as specified in Paragraph 3.2.6 
"Use of DMS Kits". 


** Medium fidelity (approx 50% functionality) DMS simulation program, sized 
based on U.S. Lab DMS estimate per Paragraph 3.2.6 “Use of DMS Kits". 
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3.2.31 Trainer Host Reconfigurability: 

a) hot backup for US Lab Module trainers 

b) reconfigurable backup for US Lab Module trainers 

c) none 


Training: 

A hot backup (Option a) for US Lab Module trainers is potentially required for 
joint integrated simulations where the cost of a PTC/SCS trainer failure would be 
enormous. Up to fifty personnel dispersed at ROCs, DOCs, and UOFs worldwide, the 
computers and trainers at these sites, and all the communications resources 
connecting them could be idled by a PTC/SCS failure. The cost of training being 
stopped for hours, and then rescheduled would be unacceptably high. A hot backup 
could provide recovery and resumption of the joint integrated simulation in under five 
minutes. 

A second potential solution to this same problem is reconfigurable backup. This 
would permit resumption of training in a known, relatively short period of time. If the 
period is some portion of an hour, this could be a cost effective alternate to Option (a). 


System; 

A true failover hot backup (Option a) for US Lab module trainers would require 
duplicate hardware from the C&D panel connections in the trainers on out to and 
including the host computers, frequent checkpoint of scenario data on a shared 
medium that is accessible to the duplicate hardware, and control software to monitor 
for failure and activate the failover when a failure occurs. 

A reconfigurable backup (Option b) can be implemented by utilizing one of the 
other equally sized hosts (the IT&V host for example) with some switches and shared 
media to connect it in place of the failed host. The DMS Kit is the problem here, but 
current DMS design indicates that duplicate internal components or a duplicate SIB 
with a cross-bar switch could be utilized. If the duplicate internal DMS Kit component 
method is used, the SIB and key internal DMS Kit components including the MPAC 
then becomes the single points of failure. This is the current CBR baseline. 

Cost; 

The costs of hot backup (Option a) are the additional host, DMS Kit, bridges, 
switches, and shared media as well as more complex SCS executive software and 
failover software. The current SIB design, however, hampers easily reconfigurable 
DMS-based trainers due to the SIB’s proprietary high speed, non-switchable point-to- 
point host connection. The SIB to DMS Kit connections, as well as flight equivalent 
payload hardware connections to MDMs, further limit the ease of reconfiguration. 

The costs of reconfigurable backup include the cost of: 
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• duplicate SIBs and a cross-bar switch or a single shared SIB with 
duplicate host ports (and duplicate DMS component capabilities) with 
duplicate connections to C&D panels 

• a duplicate MPAC (optional) 

• duplicate C&D panel to host connections with switches between the 
connections 

• a duplicate host 

• shared media to hold the required checkpoint data 

• additional patch panel routing of Audio/Video, C&T, and other 
simulation services using duplicate connections may also be necessary 


Comparison: 


(a) 

hot 

backup 


HARDWARE REQUIREMENTS 


FIXED 


A standby host, 
dual ported disks 
(2 sets), standby 
DMS Kit 
including a 2nd 
MPAC and SIB + 
dbl path switches 
for connections 
from DMS Kit to 
C&D, DMS Kit to 
MPAC, host to 
C&D + duplicate 
A-V + 2nd C&T 
processor and 
patch panel 


INCREMENTAL 


None 


SOFTWARE REQUIREMENTS 


FIXED 


8K SLOC failover 
& reconfiguration 
program in the 
Session 
Management 
Function 
+ 2K SLOC 
reconfig. module 
in each Sim Exec 
(+ common 
sim models for 
all trainers) 


INCREMENTAL 


All P/L models 
must conform to a 
a standard so 
that checkpoint 
can be done. F/E 
P/Ls may be a 
problem in this 
regard 


(b) 
reconfig 
backup 


Dual ported disks 
(2 sets), a SIB 
with duplicate 
component 
capability 
connected to 
IT&V host+ dbl 
path switches for 
connections from 
host to C&D 


None 


2K SLOC 
reconfig. module 
in each Sim Exec 
(+ common 
sim models for 
all trainers) 


All P/L models 
must conform to a 
a standard so 
that checkpoint 
can be done. F/E 
P/Ls may be a 
problem in this 
regard 


(c) 

none 


None 


None 


None 


None 
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3.2.32 Malfunction Insertion: 

a) most conceptually possible faults, predefined & real time 

b) selected faults, predefined 


Training: 

Malfunction insertion is an important part of training. Option (a) will provide the 
best training, and will permit instructors good flexibility during a simulator session 

The training value of this issue is directly proportional to the number of faults 
implemented. 

Failures and near disasters in the nuclear power industry have demonstrated 
the importance of training for serious system failures. The experience gained there 
has shown that not only should all serious faults be simulated and trained for, but that 
secondary interactive sub-system failures should also be simulated. That is, situations 
like a ruptured high pressure line doing damage to nearby electrical lines should be 
simulated. 

System: 

For Option (a), a SIB would be used with flight equivalent payloads. Inclusion of 
the SIB provides a good level of capability for fault insertion in response to scenario or 
ad hoc control. Flight equivalent payloads, combined with DMS Kits, will be 
particularly effective for training interactive faults, as demonstrated in the SCS Study 
Technical Demonstration in August ’89. Software payload models would have to be 
structured for interactive fault activation as well as containing some predefined faults 
that could be triggered during a session. 

For Option (b), a SIB may not be required. However, if the SIB is not used, 
malfunctions in flight equivalent payloads would be limited to those designed into the 
hardware. This will likely be minimal. For software simulated payloads, the faults may 
be designed into the software models either as specific perturbations, or as a general 
capability to adjust functional processing to produce error prone behavior. In either 
case, the instructors would be much more limited in their ability to create faults that 
were not thought of as the payloads were designed. Usually, the malfunctions that 
cause problems are the ones not discovered during the design phase. 


Cost: 

Option (a) requires intervention during runtime to modify model behavior and, 
consequently, must be able to monitor the state of the simulation. 

The development cost of Option (b) is less than Option (a) because it only 
requires access to software models during runtime to trigger the built-in predefined 
faults 
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HARDWARE REQUIREMENTS 


SOFTWARE REQUIREMENTS 


(a) 

most 

faults, 

pre- 

defined 

& 

realtime 


(b) 

selected 

faults, 

pre- 

defined 


FIXED 


Increase trainer 
host MIPS 1% + 
SIB or non-DMS 
SIB equivalent 
per trainer 


Instructor l/F to 
allow triggering 
of predefined 
malfunctions 


INCREMENTAL 


F/EP/L 
simulations 
provide direct 
access to 
subsystem 
internals 


F/E P/L 

simulations allow 
preprogrammed 
fault behavior 


FIXED 


DMS Kit S/W or 
equivalent and 
Sim Exec S/W or 
O/S (+ develop 
toolset) support 
ad hoc 
malfunction 


Sim Exec S/W to 
support fault 
triggering 


INCREMENTAL 


5% more SLOC 
above nominal 
P/L model for 
increased P/L 
model fidelity & 
control 


10% more SLOC 
above nominal 
P/L model for 
S/W P/L models 
with enough 
faults to allow 
preprogrammed 
fault behavior 
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3.2.33 Simulator Modes: 

a) high = auto/variable play & record plus "med" functions 

b) med = freeze, resume, and replay plus "low " functions 

c) low = stop, restart and record only 


Training: 

The differentiation in simulator modes centers around the ability to start, freeze, 
and replay sessions, at will, from any point in the scenario. In option (a), this capability 
extends to defining the points automatically, based on simulation event characteristics. 
Option (a) is also distinguished by the ability to play and replay scenarios using 
condensed and discontinuous time scales and, in general, to support all the modes 
defined in Paragraph 3.3.2.1 of Volume 3 of the SCS study, “Refined Conceptual 
Design Report”. 

Option (b) requires manual invocation of the freeze, resume, and replay 
functions. 

Option (c), on the other hand, has no capability to freeze (pause) and resume 
scenarios, or otherwise alter the course of chronological time in the scenario. 

There is great training utility in having all the features of Option (a). When a 
student experiences difficulty, the student and/or the instructor can repeat an arbitrary 
section of the scenario. The ability to start the scenario at any point is very useful in 
that a particularly difficult section can be repeated. 

System: 

For Option (a), recording and replay capabilities require the systematic capture 
of scenario and crew events in near real time, and the ability to drive a scenario from 
the resulting pre-recorded crew and, possibly, ground operator events (rather than 
actual inputs from the lab module and ground systems). Thus, all initialization and real 
time inputs to the simulation have to be extracted and stored against a time base for 
possible replay of the session. Further, any stochastic components of the simulation 
models have to be monitored and all non-deterministic values recorded against the 
same time base. 

In Option (a), the fast time, jump ahead, and other time base manipulations may 
require additional capabilities. These include coherent synchronization of events with 
discrete time jumps or sufficiently rapid model execution to achieve accelerated 
calculation of dynamic relationships. The general approach of faster cycle time would 
be the desired approach since the same software could be used. For example, the 
equivalent simulation update cycle could be increased from, say, 2 Hz to 24 Hz if a 12- 
hour flight shift were being condensed to one hour running time. This of course would 
require excess computation speed. 
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On the other hand, the coherent synchronization of events would be done by 
building software models that were passed the current time or the time since the last 
call to the models. The models themselves would then calculate the resulting stated 
based on the time variable. This is the method used in the current shuttle simulator. 
While both methods are considered in this analysis, it is most likely that the coherent 
synchronization method will actually be used. 

If the session recording function resides primarily under the Session 
Management Function rather than individual simulation executives there is potentially 
a substantial load on PTC/SCS LAN and storage. Although, storage space can be 
conserved by storing simulation parameters only when their values change, this 
approach may carry a significant overhead (in the simulation executive) for monitoring 
and detecting change. Overall, however, it is the complexity of synchronization, rather 
than storage space that will vary with these storage options. 

Option (b) is the same as Option (a) minus the "auto/variable play & record". 
This reduced functionality would require far less system resources, since the excess 
computational speed associated with "fast time and jump ahead" would be eliminated. 

Option (c) has a minimal impact on system resources. 

The inclusion of mode controls in the simulation scenarios requires additional 
capability in the scenario development system. Likewise, the execution of replay and 
jump capabilities require additional functionality in the instructor station. 

The ITVE simulation executive is expected to support all simulation modes 
required by the PTC/SCS, except resume. 

Cost: 

Options (a) and (b) assume much of the same monitor functionality as required 
for trainer fail-over in Paragraph 3.2.31, “Trainer Host Reconfigurability”. In addition, 
the system must continually capture and record the state of the simulation, or at least 
keep a running log of all trainee and instructor inputs. When rerun under the original 
scenario, this log must enable a complete replay capability. 

If the variable speed method is used to implement the “fast time" and “jump 
ahead" capability, there will be a substantial impact on the cost. While variable speed 
simulation is basically a software control function, the increase in host CPU capacity 
required will be nearly proportional to the speed of the fast-time simulation mode. 
Thus, a fast-time speed of 5 times normal will result in about a 400 percent increase in 
the CPU MIPS required to execute the simulation models. 
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Comparison; 



HARDWARE REQUIREMENTS [ 

SOFTWARE REQUIREMENTS | 

FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

high 

1 MB RAM 
capture/recording 
per second* (+ 
SIB-like I/O Ctrl) + 
add'l 2 MIPS on 
MC per P/L ** 
trainer + 300 MB 
disk or tape per 
session 

F/EP/L 
instruments 
provide direct 
access to 
internals 

F/E DMS & MDM, 
model DMS, SIB, 
Sim Exec, and 
the Session 
Management 
Function S/W 
support global 
sim. memory, and 
halt & resume 
functions 
(approx. 7K 
SLOC) 

F/E & model P/L 
S/W support 
global sim 
memory, step 
ahead, and halt & 
resume functions 

(b) 

medium 

1 MB RAM 
capture/recording 
per second* (+ 
SIB-like I/O Ctrl) + 
add’l 1 MIPS on 
MC per P/L ** 
trainer + 300 MB 
disk or tape per 
session 

F/EP/L 
instruments 
provide direct 
access to 
internals 

F/E DMS & MDM, 
model DMS, SIB, 
Sim Exec, and 
the Session 
Management 
Function S/W 
support global 
sim. memory, and 
halt & resume 
functions. 

(approx. 3K 
SLOC) 

F/E & model P/L 
S/W support 
global sim 
memory, and halt 
& resume 
functions 

(c) 

low 

1 MB RAM 
capture/recording 
per second* 

None 

F/E & sim S/W w/ 
basic reset 
control (approx. 
.5K SLOC) 

F/E & model P/L 
S/W support 
global sim 
memory 


* Assumes that a global simulation memory exists with a rate of change not 
greater than 1 MB per second (approx. 50K variable deltas) for the trainer 
session 

** Based on full payload model execution at 5 times update rate and 
corresponding MIPS (for minimal speedup) 
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3.2.34 Session Data Handling: 

a) full data capture and analysis 

b) record keeping only 


Training: 

No significant impact on training but does affect the quality of analysis of trainee 
performance. 

System: 

The recording capabilities used to accomplish session replay in Paragraph 
3.2.33, "Simulator Modes", may also be used to capture the session data necessary to 
evaluate crew (trainee) performance as well as collect scenario and schedule 
information for training records. Only the latter function, without the need for 
evaluating real time data, is included in Option (b). Option (a) would not only capture 
the crew (trainee) input script, but also external ground operations and model 
generated events and valuations. 

Primary storage capabilities, as well as statistical analysis and record keeping 
functions, would be implemented as PTC/SCS system facilities. Note that Option (a) is 
assumed to include representation of external ground operations. 

Cost: 

If either Option (a) or Option (b) of Paragraph 3.2.33, "Simulator Modes" is in 
place, there should be no additional cost involved in achieving the data capture 
functionality. The analysis function for Option (a) in the present issue, however, will 
entail additional cost for analysis software and storage facilities to retain these data 
and analysis results. The former probably represents only the cost of a COTS 
statistical package and database package plus some custom applications work - in 
total not more than 12K SLOC. Disk storage capacity could accumulate to several 
hundred megabytes before trainee data would be archived at the end of an 
increment's schedule. 
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Comparison; 



HARDWARE REQUIREMENTS 

SOFTWARE REQUIREMENTS I 

I FIXED 

INCREMENTAL 

FIXED 

INCREMENTAL 

(a) 

full data 

1 MB RAM 
capture/recording 
per second* + A- 
V recording per 
trainer 

None 

F/E & sim S/W 
supporting global 
memory or ease 
of local access + 
COTS DB & 
statistical 
analysis package 
+ programs in the 
Session 
Management 
Function (approx. 
12K SLOC) 

F/E or model P/L 
S/W supporting 
global memory or 
ease of local 
access 

(b) 

records 

only 

None 

None 

COTS DBMS + 
programs in the 
Session 
Management 
Function (approx. 
2K SLOC) 

F/E or S/W P/L 
models support 
l/F to DBMS 


* Assumes that a global simulation memory exists with a rate of change not 
greater than 1 MB per second (approx. 50K variable deltas) for the trainer 
session 
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